ReasonJun

Cursor SSH 연결 에러 해결: "Failed to install the Cursor Server"

ReasonJun — Thu, 24 Jul 2025 01:32:40 +0900

문제 발생 :

Cursor에서 AWS EC2로 원격 접속하려고 했더니 이런 에러가 떴다.

Connection to Cursor server failed: Failed to install the Cursor Server. Please check the logs for more details.

아니, SSH는 되는데 왜 Cursor만 작동을 하지 않았다.

로그 확인

/usr/libexec/grepconf.sh: line 5: grep: command not found
/etc/profile.d/which2.sh: line 4: readlink: command not found
bash: bash: command not found
debug1: Exit status 127

grep도 없고, bash도 없다는 것을 알게되었다. AWS Instance에 직접 SSH로 접속해봤다.

$ ssh -i ~/.ssh/woori-kubernetes.pem ec2-user@ec2-43-203-153-38.ap-northeast-2.compute.amazonaws.com
-bash: grep: command not found
-bash: readlink: command not found
-bash: basename: command not found

역시나 기본 명령어들을 못 찾고 있었다.

문제 원인

PATH를 확인해보니 범인을 찾았다.

/usr/local/cuda-12.2/bin${PATH:+:${PATH}}

CUDA 설정하면서 실수로 이상한 구문을 넣어놨다. 변수 확장이 제대로 안 되어서 시스템이 명령어를 못 찾는 거였다.

해결

1단계: .bash_profile 수정하기

먼저 vi를 전체 경로로 실행한다 :

/usr/bin/vi ~/.bash_profile

파일이 열리면:

i 키를 눌러서 입력 모드로 전환
# User specific environment and startup programs 아래에 이 줄 추가:
```
export PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:$PATH
```
ESC 키 누르고 :wq 입력해서 저장

2단계: .bashrc도 수정

Cursor는 가끔 non-interactive shell로 접속하기 때문에 .bashrc도 수정해야 한다:

/usr/bin/vi ~/.bashrc

파일 맨 끝에 같은 내용 추가:

Shift + G로 파일 끝으로 이동
o 키 눌러서 새 줄 만들기

똑같이 추가:

export PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:$PATH

저장하고 나오기 (ESC → :wq)

3단계: 설정 적용하고 확인

source ~/.bash_profile
source ~/.bashrc

# 이제 명령어가 제대로 작동하는지 확인
which grep
which bash
echo $PATH

4단계: Cursor에서 다시 접속

SSH 세션을 완전히 종료하고:

exit

Cursor에서 다시 Remote SSH 연결을 시도했다. 정상적으로 연결되는 것을 확인했다.

정리

결국 PATH 설정이 꼬여서 생긴 문제였다. .bash_profile과 .bashrc 둘 다 수정해야 Cursor가 제대로 접속할 수 있다는 게 포인트인것 같다. 이 글이 같은 문제로 고생하는 누군가에게 도움이 되길 바란다.

Docker 특정 포트만 외부 접속이 안 될 때: iptables NAT 무한 루프 해결기

ReasonJun — Sat, 5 Jul 2025 21:19:44 +0900

문제 상황

Docker로 서비스를 운영하던 중 기묘한 현상을 발견했다:

43001, 43030 포트: 외부 접속 ✅ 정상
43000 포트: 외부 접속 ❌ 불가능
localhost:43000: 내부 접속 ✅ 정상

더 이상한 건, Docker 컨테이너는 정상 실행 중이고, 포트도 제대로 리스닝하고 있었다는 점이다.

진단 과정

1. 기본 상태 확인

# 포트 리스닝 상태 확인
$ netstat -tuln | grep 43000
tcp6       0      0 :::43000                :::*                    LISTEN

# Docker 컨테이너 상태 확인  
$ docker ps | grep 43000
8a5bce7ee59f   aimfuse-web   "docker-entrypoint.s…"   Up 5 days (unhealthy)   0.0.0.0:43000->3000/tcp

# 내부 접속 테스트
$ curl -v http://localhost:43000/api/public/health
< HTTP/1.1 200 OK
{"status":"ok"}

컨테이너는 unhealthy 상태였지만, API는 정상 응답했다.

2. 방화벽 규칙 확인

# UFW 상태 확인
$ sudo ufw status verbose
Status: active
Default: allow (incoming), allow (outgoing), allow (routed)

# iptables 확인
$ sudo iptables -L -n -v | grep 43000
# 특별한 차단 규칙 없음

UFW는 기본 정책이 allow라서 문제가 없어 보였다.

3. NAT 테이블 확인 - 문제 발견!

$ sudo iptables -t nat -L -n -v --line-numbers | grep -A 10 -B 10 "43000\|3000"

Chain PREROUTING (policy ACCEPT)
num  target     prot opt source    destination
2    REDIRECT   tcp  --  0.0.0.0/0  0.0.0.0/0    tcp dpt:3000 redir ports 43000
3    REDIRECT   tcp  --  0.0.0.0/0  0.0.0.0/0    tcp dpt:43000 redir ports 3000

문제 원인

NAT 테이블에서 무한 루프를 발견했다!

3000 포트 → 43000 포트로 리다이렉트
43000 포트 → 3000 포트로 리다이렉트

이 두 규칙이 서로를 계속 호출하면서 무한 루프에 빠져, 결국 43000 포트로의 외부 접속이 불가능했던 것이다.

해결 방법

문제가 되는 NAT 규칙들을 제거했다:

# 문제가 되는 규칙 제거 (라인 번호 확인 후)
$ sudo iptables -t nat -D PREROUTING 3
$ sudo iptables -t nat -D PREROUTING 2

# 변경사항 확인
$ sudo iptables -t nat -L -n -v | grep -A 5 -B 5 "43000\|3000"
# 이제 Docker의 정상적인 DNAT 규칙만 남음

✅ 결과

제거된 규칙: 무한 루프를 만드는 REDIRECT 규칙들
유지된 규칙: Docker의 정상적인 포트 포워딩 (43000 → 172.20.0.6:3000)
외부 접속: 정상화!

교훈과 체크리스트

왜 이런 일이 발생했을까?

아마도 과거에 포트 리다이렉션을 테스트하다가 잘못된 규칙을 추가했고, 이를 제거하지 않았던 것 같다.

향후 방지를 위한 체크리스트

포트 문제 발생 시 점검 순서:
# 1. 포트 리스닝 확인 netstat -tuln | grep [포트번호]
# 2. Docker 상태 확인 docker ps | grep [포트번호]
# 3. 내부 접속 테스트 curl -v http://localhost:[포트번호]
# 4. iptables 일반 규칙 확인 sudo iptables -L -n -v | grep [포트번호]
# 5. NAT 테이블 확인 ⚠️ 중요! sudo iptables -t nat -L -n -v | grep [포트번호]
iptables 규칙 추가 시 주의사항:
- NAT 규칙 추가 전 기존 규칙 확인
- 테스트 후 불필요한 규칙은 즉시 제거
- 규칙 추가 시 문서화 또는 주석 남기기
정기적인 점검:
# NAT 테이블 전체 확인 sudo iptables -t nat -L -n -v --line-numbers

핵심 정리

"특정 포트만 외부 접속이 안 된다면, iptables NAT 테이블을 확인하자!"

일반적인 방화벽 규칙뿐만 아니라 NAT 테이블의 REDIRECT 규칙도 반드시 확인해야 한다. 특히 무한 루프를 만들 수 있는 상호 참조 규칙이 있는지 주의 깊게 살펴보자.

이번 경험을 통해 네트워크 문제 해결 시 NAT 테이블 확인의 중요성을 다시 한번 깨달았다. 같은 실수를 반복하지 않기 위해 이 글을 기록으로 남긴다.

Understanding the NestJS Request Lifecycle: A Deep Dive

ReasonJun — Wed, 30 Oct 2024 00:51:32 +0900

NestJS, a progressive Node.js framework, implements a sophisticated request lifecycle that ensures proper handling of incoming requests through various layers of processing. In this article, we'll break down each step of this lifecycle and understand how it helps in building robust applications.

The Request Journey

1. Middleware Layer

Purpose: Handles common HTTP operations
Functionality:
- Pre-processes requests
- Handles cross-cutting concerns like logging
- Authentication headers processing
- CORS handling
Key Point: Executes before route handlers, can modify request/response objects

2. Guard Layer

Purpose: Authorization and permission checking
Functionality:
- Determines if a request should proceed
- Handles user authentication status
- Role-based access control
Example Use Case: Checking if a user is logged in before accessing protected routes

3. Interceptor (Pre-Controller)

Purpose: Request/Response transformation
Functionality:
- Adds custom headers
- Transforms request data
- Handles timing and logging
Note: Executes both before and after route handler

4. Pipe Layer

Purpose: Data validation and transformation
Functionality:
- Validates input data
- Transforms payload to desired format
- Type conversion
Common Use: DTO validation, parameter transformation

5. Controller Layer

Purpose: Route handling and business logic coordination
Functionality:
- Handles incoming requests
- Coordinates with services
- Returns responses
Best Practice: Keep controllers thin, delegate business logic to services

6. Service Layer

Purpose: Business logic implementation
Functionality:
- Implements core business rules
- Processes data
- Coordinates with repositories
Key Point: Contains reusable business logic

7. Repository Layer

Purpose: Data access and persistence
Functionality:
- Database operations
- Data retrieval and storage
- Query handling

8. Exception Filter Layer

Purpose: Error handling and formatting
Functionality:
- Catches unhandled exceptions
- Formats error responses
- Ensures consistent error handling

9. Interceptor (Post-Controller)

Purpose: Response transformation
Functionality:
- Transforms response data
- Adds metadata
- Handles logging and timing

Best Practices

Separation of Concerns
- Each layer should have a single responsibility
- Avoid mixing business logic in controllers
- Use appropriate decorators for each layer
Error Handling
- Implement custom exception filters for specific use cases
- Use built-in HTTP exceptions
- Handle errors at appropriate layers
Validation
- Use DTOs for request validation
- Implement custom pipes for complex validations
- Validate early in the request lifecycle
Performance
- Keep middleware light and focused
- Use caching where appropriate
- Implement proper logging strategies

Conclusion

Understanding the NestJS request lifecycle is crucial for building efficient and maintainable applications. Each layer serves a specific purpose and, when used correctly, contributes to a well-structured application that's easy to test and maintain.

The lifecycle ensures that requests are properly validated, authorized, and processed while maintaining clean separation of concerns. By following the best practices and understanding how each layer interacts, you can build robust applications that are both performant and maintainable.

Additional Resources

Tailwindcss : Carousel Dynamic width control

ReasonJun — Tue, 15 Oct 2024 12:16:10 +0900

Problem :

I wrote the Carousel code as shown below. I wanted the width of the carousel to be responsive to the screen size, but it wasn't, so I specified a maximum width for each screen size : "max-w-sm xs:max-w-md sm:max-w-xl md:max-w-3xl lg:max-w-5xl xl:max-w-7xl". It adjusted well to the screen size, but the problem was that there were often black spaces.

<div
        className="flex overflow-x-scroll overscroll-x-auto scroll-smooth py-12 [scrollbar-width:none]"
        ref={carouselRef}
        onScroll={checkScrollability}
      >
        <div className="mx-auto flex flex-row justify-start gap-3 pl-4 sm:gap-4">
          {items.map((item, index) => (
            <motion.div
              initial={{ opacity: 0, y: 20 }}
              animate={{
                opacity: 1,
                y: 0,
                transition: {
                  duration: 0.5,
                  delay: 0.1 * index,
                  ease: "easeOut",
                },
              }}
              key={`card${index}`}
              className="rounded-3xl md:last:pr-[calc(50%-1rem)] lg:last:pr-[33%]"
            >
              {item}
            </motion.div>
          ))}
        </div>
      </div>

Why :

width doesn't move responsively in a carousel for the following reasons :

Fixed width on items: The code doesn't show how the individual items are styled. If the items have a fixed width, they won't resize responsively.
Overflow behavior: The carousel is set to overflow-x-scroll, which allows horizontal scrolling but doesn't automatically resize content.

Solution :

I wrapped this code and it worked.

<div className="relative w-[90vw] max-w-7xl">

Why :

w-[90vw]: This sets the width to 90% of the viewport width, which makes the container responsive to the screen size.
max-w-7xl: This sets a maximum width (in Tailwind, this is typically 1280px), preventing the carousel from becoming too wide on large screens.
relative: This establishes a new positioning context for absolute elements inside the carousel (like the navigation buttons).

postgresql (Supabase) : security definer set search_path = '' (Security Problem)

ReasonJun — Tue, 6 Aug 2024 15:53:31 +0900

Securing PostgreSQL Functions in Supabase: Addressing Search Path Vulnerabilities

In the world of database management and application development, security is paramount. Recently, while working on a Supabase project utilizing PostgreSQL functions, I encountered a security warning that led us down a path of discovery and improvement. This blog post will walk you through our journey from identifying the problem to implementing a robust solution.

The Problem: "Search Path Mutable" Warning

My story begins with a seemingly innocuous PostgreSQL function in our Supabase project. Upon deployment, we were greeted with a warning from the Supabase advisor:

This cryptic message was our first indication that something wasn't quite right with our function's security posture. The function in question was designed to delete and insert data related to toxic tactics for a given subject. Here's a simplified version of our initial function:

CREATE OR REPLACE FUNCTION public.delete_and_insert_toxic_tactics_subject(p_subject_id TEXT, p_new_data JSONB)
RETURNS VOID
AS $$
-- Function body
$$ LANGUAGE plpgsql;

Understanding the Vulnerability

The "search_path mutable" warning points to a potential security vulnerability related to PostgreSQL's search path mechanism. In PostgreSQL, the search path determines the order in which schemas are searched when an unqualified object name is used.

This vulnerability arises because:

The search path can be changed by users during their session.
If the function doesn't explicitly set its search path, it inherits the search path of the calling user.
This inherited search path could potentially be manipulated to make the function access unintended objects or schemas

In my case, this was particularly concerning because our function was dealing with sensitive data related to toxic tactics. Any unintended access or manipulation could have serious consequences.

The Solution: SECURITY DEFINER and Empty Search Path

After careful consideration and testing, I arrived at a solution that effectively addresses this vulnerability. Here's my updated function definition :

CREATE OR REPLACE FUNCTION public.delete_and_insert_toxic_tactics_subject(p_subject_id TEXT, p_new_data JSONB)
RETURNS VOID
SECURITY DEFINER
SET search_path = ''
AS $$
DECLARE
  uuid_subject_id UUID;
  inserted_count INT := 0;
  expected_count INT;
  current_tactic TEXT;
  log_messages TEXT[] := ARRAY[]::TEXT[];
  total_average FLOAT;
  tactic_scores JSONB;
BEGIN
  -- Function body with fully qualified object names
  -- For example:
  -- INSERT INTO public."red toxic tactic" (...)
END;
$$ LANGUAGE plpgsql;

Let's break down the critical components of this solution :

1. SECURITY DEFINER

The SECURITY DEFINER clause ensures that the function executes with the privileges of its owner (creator) rather than those of the calling user. This provides a consistent security context for the function's execution.

2. SET search_path = ''

This is the crux of my solution. By setting the search path to an empty string, we're effectively clearing the search path for this function. This has several important implications :

It forces all object references within the function to be fully qualified with their schema names.
It prevents any possibility of search path-based attacks, as there's no search path to manipulate.
It ensures predictable behavior regardless of the calling user's search path settings.

3. Fully Qualified Object Names

With an empty search path, it becomes crucial to use fully qualified names for all database objects within the function body. For example:

INSERT INTO public."red toxic tactic" (column1, column2) VALUES (...);

React : createPortal

ReasonJun — Sat, 13 Jul 2024 22:30:31 +0900

Env :

Nextjs 14, shadcn

Problem :

I want Tooltip to be placed at the top, but the z-index value is not applied due to the rendering order in Dom.

Fix :

use createPortal

What is createPortal ? (Cluade Sonnet 3.5 Answer)

Certainly. `createPortal` is a powerful feature provided by React that allows you to render a component's children into a different part of the DOM tree, outside of the component's own hierarchy. Here's a detailed explanation:

1. Purpose:
   - `createPortal` is used to render children into a DOM node that exists outside the DOM hierarchy of the parent component.
   - It's particularly useful for creating modals, tooltips, pop-ups, or any floating UI elements that need to "break out" of their container's bounds.

2. Import:
   - It's imported from the 'react-dom' library:
     ```javascript
     import { createPortal } from 'react-dom';
     ```

3. Basic syntax:
   ```javascript
   createPortal(child, container)
   ```
   - `child`: The React element, string, or fragment to render.
   - `container`: The DOM element to render the portal into.

4. Usage example:
   ```jsx
   function Modal({ children }) {
     return createPortal(
       children,
       document.body
     );
   }
   ```

5. Key benefits:
   - Avoids CSS stacking context issues
   - Allows components to render content outside of their own DOM hierarchy
   - Useful for components that need to "escape" containers with `overflow: hidden` or `z-index` stacking

6. Event bubbling:
   - Events from portals will bubble up through the React tree, regardless of where they're rendered in the DOM.
   - This maintains React's expected behavior even when using portals.

7. Use cases:
   - Modals
   - Tooltips
   - Floating menus
   - Notification systems
   - Any UI that needs to overlay the main application regardless of DOM structure

8. Considerations:
   - Portals should be used judiciously, as they can complicate the application structure if overused.
   - It's important to manage focus and accessibility properly when using portals for modals or dialogs.

In the context of your tooltip issue, using `createPortal` could help ensure that the tooltip content always renders at the root level of the DOM, avoiding any potential stacking context problems caused by intermediate container elements.

Here's how you might use it in your Sidebar component:

```jsx
import { createPortal } from 'react-dom';

// Inside your component's return statement
{SIDEBAR_ITEMS.map((item, idx) => {
  // ... other code ...
  return (
    <Tooltip key={idx} delayDuration={0}>
      <TooltipTrigger asChild>
        {/* ... */}
      </TooltipTrigger>
      {createPortal(
        <TooltipContent className="z-50" side="right">
          {item.title}
        </TooltipContent>,
        document.body
      )}
    </Tooltip>
  );
})}
```

This approach would render the tooltip content directly into the document body, ensuring it's not constrained by any parent elements' stacking contexts.

Dual Monitor Development Error: Cursor Pointer and Screen Views

ReasonJun — Thu, 6 Jun 2024 17:19:38 +0900

Problem :

I am currently using an M1 PRO MacBook with dual monitors in FULL-HD quality. I have my code on the MacBook screen and the webview on the dual monitors. I thought it would work fine, but the cursor pointer doesn't work in FULL-HD and the CSS event effects look different.

m1 pro macbook screen :

Screen Recording 2024-06-06 at 5.15.51 PM.mov

4.53MB

full-hd screen :

Screen Recording 2024-06-06 at 5.16.25 PM.mov

2.59MB

GPT 4O says it may have the following issues :

Explanation for CSS Event and Cursor Pointer Issues on Dual Full-HD Monitors with M1 Pro MacBook

Using dual monitors with Full-HD resolution on an M1 Pro MacBook, where the MacBook screen displays code and the dual monitor displays a web view, might seem like it should work without issues. However, if the cursor pointer and CSS event effects do not work correctly on the Full-HD monitors, there could be several reasons for this. Here are some possible explanations:

1. Resolution and DPI Settings Issue

Differences in resolution or DPI settings between the MacBook and the dual monitors can cause CSS effects or cursor pointers to not work as expected. This is especially true when using a Retina display and a non-Retina display together.

Solution: Check the display settings in System Preferences and adjust the resolution and DPI settings. Try matching the resolution of both monitors or adjusting the scaling.

2. Browser Compatibility Issue

CSS effects might look different on specific browsers or browser versions. In a dual monitor setup, the browser might render differently on each monitor.

Solution: Test the web page on different browsers to see if the issue is specific to one browser. Update the browser to the latest version or try using a different browser.

3. CSS Code Issue

There might be issues within the CSS code itself, causing bugs that appear only at certain resolutions.

Solution: Use media queries in your CSS to apply styles specific to Full-HD resolution. For example:

@media (max-width: 1920px) {
  .your-class {
    cursor: pointer;
    /* other styles */
  }
}

4. Hardware Acceleration Issue

The browser's hardware acceleration feature might cause problems, especially in a dual monitor setup.

Solution: Turn off or on the hardware acceleration in the browser settings and see if this resolves the issue.

5. Operating System and Driver Issue

There might be issues with the MacBook's operating system or graphics drivers, particularly after a new OS update.

Solution: Update macOS and graphics drivers to the latest version. Also, recheck the display settings in System Preferences.

6. Specific Web Page Issue

If the issue occurs only on a specific web page or web application, there might be a problem with the code of that particular page.

Solution: Inspect the code of the problematic web page and test if the same issue occurs on other pages.

Try these methods one by one to resolve the issue. If the problem persists, please provide more specific information for further assistance.

ZKP : Practice and Understand

ReasonJun — Sun, 19 May 2024 20:44:10 +0900

Overview of Zero-Knowledge Proofs (ZKPs)

Zero-Knowledge Proofs (ZKPs) are cryptographic methods that allow a prover to convince a verifier that a given statement is true without revealing any additional information beyond the validity of the statement itself. Key concepts include:

Statement: The proposition or computation that needs to be proven.

Witness: The private information that proves the statement.

Prover: The entity that proves the statement.

Verifier: The entity that verifies the proof.

1. Writing the Circuit (Arithmetic Constraints)

Circom is a domain-specific language for defining arithmetic circuits that represent the constraints of a ZKP. The example circuit provided is as follows:

pragma circom 2.0.0;

template Demo() {
    signal input x;
    signal input y;
    signal input z;
    signal input out;
    signal T1;
    T1 <== (x - 2) * (y + 3);
    signal T2;
    T2 <== (z + 4) * (z + 5);
    out === T1 * T2 + 6;
}

component main {public [out]} = Demo();

This circuit takes inputs x, y, and z, and calculates intermediate signals T1 and T2, which are then used to compute the output out. The constraints ensure that the output is correctly derived from the inputs according to the defined arithmetic operations.

2. Installing Circom and Snarkjs

Circom and Snarkjs are essential tools for compiling circuits and generating proofs. The installation steps are as follows:

# Install Circom
git clone <https://github.com/iden3/circom.git>
cd circom
cargo build --release

# Install Snarkjs
git clone <https://github.com/iden3/snarkjs.git>
cd snarkjs
npm install
npm run build

Circom is a Rust-based compiler for arithmetic circuits, while Snarkjs is a JavaScript library for generating and verifying zk-SNARKs.

3. Compiling the Circuit

Once the circuit is written, it needs to be compiled into an R1CS (Rank-1 Constraint System) file, which represents the constraints of the circuit.

~/circom/target/release/circom --r1cs --sym --json --O0 --output build demo.circom

This command compiles demo.circom into several files:

demo.r1cs: The constraints of the circuit.
demo.sym: Symbolic representation of the circuit.
demo.json: JSON representation of the circuit.

4. Inspecting the Constraints

Snarkjs can be used to inspect the constraints defined in the R1CS file.

~/snarkjs/build/cli.cjs r1cs print build/demo.r1cs build/demo.sym

This command prints out the constraints in a human-readable format, allowing you to verify that the circuit was compiled correctly.

5. Calculating the Witness

The witness is a set of values that satisfy the circuit's constraints given certain inputs. The witness is computed using a WebAssembly (WASM) file generated by Circom.

# Generate the witness
node build/demo_js/generate_witness.js build/demo_js/demo.wasm input.json build/demo_js/witness.wtns

# Export the witness to JSON
~/snarkjs/build/cli.cjs wtns export json build/demo_js/witness.wtns wtns.json

input.json contains the input values for the circuit, and witness.wtns is the computed witness file.

6. Setting Up (Proving and Verification Keys)

Using the Groth16 protocol, you generate proving and verification keys. These keys are essential for creating and verifying proofs.

# Generate proving and verification keys
~/snarkjs/build/cli.cjs groth16 setup build/demo.r1cs ptau_file demo.zkey

# Export the verification key
~/snarkjs/build/cli.cjs zkey export verificationkey demo.zkey vk.json

ptau_file is a Powers of Tau file used for the initial setup. demo.zkey contains the proving and verification keys.

7. Generating and Verifying the Proof

With the proving key, you can generate a proof, and with the verification key, you can verify it.

# Generate the proof
~/snarkjs/build/cli.cjs groth16 prove demo.zkey build/demo_js/witness.wtns proof.json public.json

# Verify the proof
~/snarkjs/build/cli.cjs groth16 verify vk.json public.json proof.json

proof.json contains the generated proof, and public.json contains the public inputs. The verification step checks if the proof is valid given the public inputs and the verification key.

https://hackmd.io/@vTR2f7tjRgKq_E5Vfkw_vw/rJHd5NyHp

1. Flatten the Problem Polynomial and Construct the Corresponding Circuit

This step is performed by the upper-level application and involves the following tasks:

Flattening the Problem Polynomial: This involves transforming the problem into a polynomial form that can be expressed as a circuit. For example, breaking down a complex computation into a series of simple arithmetic operations.
Constructing the Circuit: Based on the flattened polynomial, a logical circuit is designed. This circuit consists of inputs, outputs, and a series of gates (operations) that perform the necessary computations.

2. Generate R1CS (Rank-1 Constraint System) According to the Circuit

R1CS is a system of constraints that represents the circuit. Each constraint is expressed using three vectors a, b, c

and must satisfy the following equation:

<a,z>·<b,z> = <c,z>

where z is a vector that includes all variables and 1. In this step, each gate and connection in the circuit is translated into an R1CS constraint, creating a system of equations that the circuit must satisfy.

3. Convert R1CS to QAP (Quadratic Arithmetic Program)

QAP is a polynomial-based constraint system derived from R1CS. The conversion process involves:

Traditional Lagrange Interpolation: This method finds polynomials that pass through a given set of points. However, it can be computationally expensive.
Fast Fourier Transform (FFT): FFT is an algorithm that can quickly evaluate and interpolate polynomials. Using FFT, the polynomials A(x), B(x), C(x) for the QAP can be generated more efficiently, reducing the computational complexity to O(n log n).

4. Setup Parameters of the QAP Problem, i.e., CRS (Common Reference Strings)

CRS are common reference strings that include parameters necessary for proof generation and verification. This step involves:

Generating the CRS: Based on the QAP polynomials, the CRS is generated.
Setting Common Parameters: The generated CRS is used to establish common parameters that both the prover and verifier will use.

5. Create Proof Based on CRS and Input

In this step, the proof is generated using the CRS and the input values:

Preparing Inputs: The inputs to the circuit are prepared.
Generating the Proof: Using the prepared inputs and the CRS, the proof is generated. This involves using the QAP polynomials and the input values to produce proof data.
Proof Data: The generated proof data is in a format that can be verified by the verifier.

6. Verify Proof

The verification step involves the following tasks:

Receiving Proof Data: The verifier receives the proof data generated by the prover.
Verification Process: Using the received proof data and the CRS, the verifier checks the validity of the proof. This involves using the QAP polynomials and the common parameters to ensure the proof is correct.
Result Confirmation: Based on the verification process, the verifier determines whether the proof is valid. If valid, it confirms that the statement being proven is true.

Summary

This overall process is designed to securely prove and verify complex computational problems. Each step transforms the problem into a polynomial form, generates a constraint system (R1CS), converts it to a polynomial-based system (QAP), and uses common reference strings (CRS) to efficiently generate and verify proofs. Using Fast Fourier Transform (FFT) reduces computational complexity, making the proof generation and verification process more efficient. The CRS enables both the prover and verifier to use common parameters, ensuring the integrity and security of the proof system.

Nextjs 14 & Clerk V5 beta & middleware Problem

ReasonJun — Sat, 2 Mar 2024 00:36:17 +0900

error :

While setting up the middleware to utilize the new clerk, I created the middleware with a different name so that it would not be activated for ease of development. Then the above error occurred. When I checked, the clerk was using its own jwt system and was unable to retrieve session data as a header, so it was relying on the auth system in middleware. Therefore, the server side clerk module could not be used unless middleware was activated. After reactivating middlware, the above code worked normally.

Tailwindcss : justify-center and Accordian height Problem

ReasonJun — Wed, 21 Feb 2024 18:48:32 +0900

Problem :

In the CSS code surrounding the outermost tag as shown below, justify-center provided a problem with height when accordian was activated.

When justify-center is applied in h-screen, the top component is cut off when Accordian, which provides dynamic height, is activated.

Solution :

When justify-center was removed, the height value was modified based on the content, and no components were cut off even when Accordian was activated.

Drizzle ORM - SQL Types

ReasonJun — Mon, 5 Feb 2024 14:27:44 +0900

Integer

Signed 4 Bytes

export const testTable = pgTable("testTable", {
qty: integer("qty")
})

Signed 2 Bytes

export const testTable = pgTable("testTable", {
qty: smallint("qty")
})

Signed 8 Bytes

export const testTable = pgTable("testTable", {
qty: bigint("qty", {mode: "number"})
// {mode: "number"} : 2^31 < number < 2^53
// {mode: "bigint"} : 2^63 < number < 2^63
})

serial

serial / serial4 : is an auto-incrementing 4-byte integer generally used for creating unique identifiers.

export const testTable = pgTable("testTable", {
id: serial("id"").primaryKey(),
})

smallserial / serial2 : is an auto-incrementing 2-byte integer

export const testTable = pgTable("testTable", {
id: smallserial("id")
})

bigserial / serial8 : is an auto-incrementing 8-byte integer suitable for larger ranges of integers.

export const testTable = pgTable("testTable", {
id: bigserial("id", {mode: "bigint"}).primaryKey(),
})

decimal

The decimal type in Drizzle ORM is an alias for the numeric type, and it is used to represent exact numerics with selectable precision. This means that it can store numbers with a very large number of digits, up to 131072 digits before the decimal point and up to 16383 digits after the decimal point

export const testTable = pgTable("testTable", {
price: decimal("price", {precision:7, scale:2}) // 12345.67
===
price: numeric("price", {precision:7, scale:2}) // 12345.67
})

real / float4

Single precision floating-point number (4 bytes)

IE-37 to IE+37

6 decimal digits precision

It follows IEEE 754, and some errors may occur when dealing with floating point types.
It cannot be converted accurately and is stored as an approximate value, so it is not suitable for exact calculations.

export const testTable = pgTable("testTable", {
	score: real("score")
})

double presition / float8

Double precision floating-point number (8 bytes)

15 decimal digits precision

export const testTable = pgTable("testTable", {
	score: doublePrecision("score")
})

Defi : Atomic Swap

ReasonJun — Thu, 18 Jan 2024 12:28:24 +0900

What are they?

Imagine trading directly with someone holding a different cryptocurrency than yours, without worrying about counterparty risk or needing a trusted third party like an exchange. That's what atomic swaps allow you to do.
They leverage "Hashed Timelock Contracts (HTLCs)," smart contracts on each blockchain that act as temporary vaults holding both parties' assets.

How do they work?

Agreement & Preperation: Two parties agree on the swap terms (amount, currencies, time limit) and use dedicated wallets or platforms supporting atomic swaps.
Depositing Assets: Both parties lock their designated amount of crypto into separate HTLCs on their respective blockchains.
Timelock and Exchange: Each HTLC sets a time limit for the other party to complete the swap. If both deposits happen within the timeframe, the HTLCs release the assets to the recipient's respective blockchain.
Refund or Timeout: If either party fails to deposit within the set time, the HTLCs automatically return the locked assets to their original owners.

Benefits of Atomic Swaps:

Decentralization: Eliminates the need for centralized exchanges, promoting individual control and trustless peer-to-peer transactions.
Greater Liquidity: Enables trading between tokens on different blockchains, unlocking previously isolated liquidity pools.
Security: HTLCs ensure no party loses their assets unless the swap completes successfully, minimizing counterparty risk.
Privacy: Direct peer-to-peer transactions potentially enhance privacy compared to exchange usage.

Challenges and Future:

Limited Support: Atomic swaps are still a relatively new technology, and support for diverse token pairs and platforms is evolving.
Technical Complexity: Setting up and using atomic swaps can be more complex than traditional exchange trading, requiring some technical knowledge.
Security Considerations: While secure in principle, vulnerabilities could exist in specific implementations or smart contract code.

Despite these challenges, atomic swaps represent a significant step forward in decentralized finance and cross-chain interoperability. As the technology matures and gains wider adoption, it has the potential to revolutionize how we trade and interact with digital assets across different blockchains.

https://chain.link/education-hub/atomic-swaps#:~:text=Atomic%20swaps%20are%20a%20way,the%20multi%2Dchain%20Web3%20ecosystem.

Ethereum : Gas / EIP-1559

ReasonJun — Wed, 17 Jan 2024 19:53:57 +0900

Gas

This refers to the value used for fees in Ethereum. The fee is calculated by converting the Byte Code that appears when the code in the Smart Contract is complied into the Gas value specified in the OP_CODE table.

Gas Limit(Used)

Gas Limit is divided into Block Gas Limit and Transaction Gas Used. Block Gas Limit means the sum of the total Transaction Gas Used in the corresponding block, and Transaction Gas Used is the total amount of Gas used in executing the corresponding transaction.

Gas Price

Gas Price is a value used to determine how quickly the transaction will be executed. The minimum Gas Price value changes dynamically depending on the network status.

EIP-1559

EIP-1559, implemented in August 2021, marked a significant upgrade for Ethereum by overhauling how transaction fees, aka "gas fees," are calculated and processed. Here's a breakdown of its key features and impacts:

Before EIP-1559:

Auction-based fees: Users bid on gas prices, leading to unpredictable costs and favoring miners willing to accept lower fees, potentially delaying transactions.
Volatile fee market: Difficulty estimating fees, discouraging casual users and hindering ecosystem growth.
Miner-centric: Miners captured most of the fees, potentially impacting Ethereum's long-term value proposition.

EIP-1559 introduces a new fee structure:

Base fee: A dynamic, algorithm-determined fee for inclusion in the next block, adjusting based on network congestion.
Max fee: Users specify the maximum they're willing to pay, including a "tip" for miners for faster processing.
Priority fee: Optional tip portion of the max fee to incentivize miners.
Burn mechanism: Portions of the base fee are permanently burned, reducing ETH supply over time.

Impacts of EIP-1559:

More predictable fees: Base fee provides a baseline, improving cost estimation and user experience.
Smoother fee market: Dynamic base fee adjusts to demand, potentially decreasing volatility.
Reduced fee capture for miners: Transitioning to a more predictable and value-driven fee model.
Potential deflationary effect: Burning base fees can decrease ETH supply in the long run, impacting its value.

Overall, EIP-1559 aims to achieve:

Fairer and more efficient fee market: Balancing user needs, miner incentives, and network stability.
Enhanced user experience: Making fee estimation and transaction planning easier.
Sustainable economic model: Introducing a potential deflationary mechanism for Ethereum.

https://www.youtube.com/watch?v=MGemhK9t44Q

Base Fee

This is the basic fee amount to be provided to miners. The next Base Fee is calculated depending on how many transactions were filled in the previous Block, and can increase or decrease by up to 12.5%.

Max Priority Fee

This is the amount of fee to be provided to the miner in addition to the base fee.

Max Fee Per Gas

This is the maximum Gas Price value that can be provided to miners.

Fee calculation

min ( MaxFee - BaseFee, MaxPriorityFee)

Ethereum: EIP-2770 (Standardizing Meta Transactions in Ethereum)

ReasonJun — Wed, 17 Jan 2024 00:12:39 +0900

EIP-2770 is a proposed Ethereum Improvement Proposal (EIP) aimed at standardizing the way meta transactions are executed within the Ethereum ecosystem. Meta transactions enable users to sign and submit transactions to the blockchain without having to pay the gas fees themselves. This can be beneficial for various reasons, like:

Reducing barriers to entry: By removing the gas fee burden, EIP-2770 could make it easier for new users to interact with dApps and experience the benefits of blockchain technology.
Improving accessibility: EIP-2770 can be particularly helpful for users with limited resources, such as those in developing countries or with low computing power.
Enabling innovative applications: The ability to offload gas fees opens up possibilities for new dApp functionalities, such as micropayments, loyalty programs, and subscription services.

How does EIP-2770 work?

EIP-2770 defines a standard interface for "forwarder contracts." These contracts act as intermediaries between the actual user (signer) and the target smart contract they wish to interact with. When a user wants to initiate a meta transaction:

They sign the transaction data and a special permit message using their private key.
The signature and permit message are sent to the forwarder contract.
The forwarder contract verifies the signature and uses its own funds to pay the gas fees for the transaction.
The transaction is submitted to the Ethereum blockchain for execution.

Current status of EIP-2770:

While EIP-2770 was proposed in 2021, it hasn't yet been officially adopted by the Ethereum community. There are ongoing discussions about its technical merits and potential downsides.

Some concerns regarding EIP-2770 include:

Centralization: Forwarder contracts introduce a centralized point of failure, which could potentially compromise the security and censorship resistance of the Ethereum network.
Security vulnerabilities: As with any smart contract functionality, there's a risk of bugs or vulnerabilities within the forwarder contracts that could be exploited by attackers.
Potential for abuse: Malicious actors could potentially use meta transactions to spam the network or engage in other harmful activities.

Despite these concerns, EIP-2770 continues to be a topic of active discussion within the Ethereum community. Its potential benefits for usability and adoption are making it a serious contender for future integration into the Ethereum protocol.

Additional resources:

EIP-2770 specification: https://github.com/ethereum/EIPs/issues/2585
Discussion on OpenZeppelin forum: https://ethereum.stackexchange.com/questions/119462/eip-2771-is-it-possible-to-pay-a-function-with-froms-eth-not-the-forwarder-co
Article on Medium: https://medium.com/biconomy/the-meta-transaction-flow-ed98cd750ef0

Ethereum : Transaction Receipt

ReasonJun — Wed, 17 Jan 2024 00:02:55 +0900

https://github.com/ethereum/go-ethereum/blob/master/core/types/receipt.go

Type: The type of transaction (e.g., LegacyTxType, AccessListTxType).
PostState: The root hash of the world state after transaction execution.
Status: The transaction's status (1 for success, 0 for failure).
CumulativeGasUsed: Total gas used by the transaction and its sub-transactions.
Bloom: A Bloom filter for efficient retrieval of logs matching specific topics.
Logs: An array of logs emitted during transaction execution.
TxHash: Hash of the transaction.
ContractAddress: Address of the created contract (if applicable).
GasUsed: Gas used by the transaction itself.
EffectiveGasPrice: Effective gas price paid for the transaction.
BlobGasUsed: Gas used for any internal calls or contract creation (EIP-4399).
BlobGasPrice: Gas price for blob transactions (EIP-4399).
BlockHash: Hash of the block containing the transaction.
BlockNumber: Number of the block containing the transaction.
TransactionIndex: Position of the transaction within the block.

Ethereum : Transaction Structure

ReasonJun — Tue, 16 Jan 2024 23:38:24 +0900

Transaction is a structure used when EOA transmits Eth to EOA or when EOA calls CA.

txType() byte: This method returns the type ID of the transaction. It is expected to return a byte representing the type of the transaction.
copy() TxData: This method creates a deep copy of the transaction data, initializing all fields. It allows for the duplication of transaction data.
chainID() *big.Int: Returns the chain ID associated with the transaction.
accessList() AccessList: Returns the access list associated with the transaction. An access list is a list of addresses and storage keys that the transaction plans to access, providing a way to optimize gas calculations.
data() []byte: Returns the transaction data as a byte slice.
gas() uint64: Returns the amount of gas specified for the transaction.
gasPrice() *big.Int: Returns the gas price set for the transaction.
gasTipCap() *big.Int: Returns the maximum gas tip that the transaction is willing to pay.
gasFeeCap() *big.Int: Returns the maximum fee (gas price * gas limit) that the transaction is willing to pay.
value() *big.Int: Returns the value of ether being transferred with the transaction.
nonce() uint64: Returns the nonce of the transaction.
to() *common.Address: Returns the recipient address of the transaction.
rawSignatureValues() (v, r, s *big.Int): Returns the raw signature values (v, r, s) of the transaction.
setSignatureValues(chainID, v, r, s *big.Int): Sets the signature values for the transaction, including the chain ID, v, r, and s.
effectiveGasPrice(dst *big.Int, baseFee *big.Int) *big.Int: Computes the effective gas price paid by the transaction, given the inclusion block baseFee. The result is returned as a big.Int. The dst parameter is provided to store the result, and it emphasizes that the returned value should be an independent copy.
encode(*bytes.Buffer) error: Encodes the transaction data into a byte buffer. This is likely used for serialization purposes.

EOA - EOA Transaction

EOA - CA Transaction

Ethereum : Block Structure

ReasonJun — Tue, 16 Jan 2024 18:46:15 +0900

Block represents an Ethereum block.

Note the Block type tries to be 'immutable', and contains certain caches that rely on that. The rules around block immutability are as follows:

We copy all data when the block is constructed. This makes references held inside the block independent of whatever value was passed in.

We copy all header data on access. This is because any change to the header would mess up the cached hash and size values in the block. Calling code is expected to take advantage of this to avoid over-allocating!

When new body data is attached to the block, a shallow copy of the block is returned. This ensures block modifications are race-free.

We do not copy body data on access because it does not affect the caches, and also because it would be too expensive.

https://github.com/ethereum/go-ethereum/blob/master/core/types/block.go

Header

https://github.com/ethereum/go-ethereum/blob/master/core/types/block.go

ParentHash (common.Hash):
- Represents the hash of the parent block's header. It helps establish the chronological order and linkage of blocks in the blockchain.
UncleHash (common.Hash):
- Represents the hash of the uncle blocks. Uncle blocks are valid blocks that are not included in the main blockchain but still contribute to the security of the network.
Coinbase (common.Address):
- Represents the address of the miner who successfully mined this block and is entitled to the block reward.
Root (common.Hash):
- Represents the root hash of the state trie after all transactions in the block have been executed.
TxHash (common.Hash):
- Represents the root hash of the Merkle trie containing all transactions in the block.
ReceiptHash (common.Hash):
- Represents the root hash of the Merkle trie containing all transaction receipts.
Bloom (Bloom):
- Represents a Bloom filter, a data structure used to efficiently test whether an element is a member of a set. In Ethereum, it's used to filter and quickly query logs.
Difficulty (big.Int):
- Represents the difficulty of finding a valid hash for the block. It adjusts dynamically to control the rate at which new blocks are added to the blockchain.
Number (big.Int):
- Represents the block number, indicating the position of the block in the blockchain.
GasLimit (uint64):
- Represents the maximum amount of gas that can be used in this block.
GasUsed (uint64):
- Represents the total amount of gas used by all transactions in the block.
Time (uint64):
- Represents the timestamp indicating when the block was mined.
Extra ([]byte):
- Represents additional data that miners can include in the block.
MixDigest (common.Hash):
- Represents the mix hash used in Ethash mining.
Nonce (BlockNonce):
- Represents a 64-bit hash, used in the mining process to try different combinations to find a valid block hash.
BaseFee (big.Int):
- Added by Ethereum Improvement Proposal (EIP)-1559, represents the base fee per gas unit.
WithdrawalsHash (common.Hash):
- Added by EIP-4895, represents the hash of withdrawals from the Ethereum 2.0 beacon chain.
BlobGasUsed (uint64):
- Added by EIP-4844, represents the gas used by the Ethereum 2.0 blob.
ExcessBlobGas (uint64):
- Added by EIP-4844, represents the excess gas in Ethereum 2.0 blob.
ParentBeaconRoot (common.Hash):
- Added by EIP-4788, represents the root of the parent beacon block in Ethereum 2.0.

Block Production

1. Mempool Tx choose

2. EVM execution

3. Transaction execution ( Receipt, Log produce)

4. Block Header Generate

5. Find Nonce, MixHash (ethHash)

6. Block Propagation

HTML : IndexedDB

ReasonJun — Mon, 8 Jan 2024 15:59:26 +0900

IndexedDB is a powerful API provided by web browsers for managing a local NoSQL database within client-side applications. Here's a detailed breakdown of its key features and functionalities:

Purpose:

Persistently store large amounts of structured data in the user's browser, enabling offline-capable web applications.
Offer rich query capabilities for efficient data retrieval based on indexes.

Key Concepts:

Object stores: The fundamental data structure, resembling tables but holding JavaScript objects instead of rows and columns.
Keys: Unique identifiers used to access individual objects within an object store.
Indexes: Specialized structures built on top of object stores for fast searching based on specific data properties.
Transactions: Groups of operations ensuring data consistency by committing all changes or reverting them entirely in case of an error.

Advantages:

Large storage capacity: Compared to Web Storage, IndexedDB allows storing significantly more data (multiple megabytes to gigabytes).
Offline persistence: Data survives across browser sessions and even device reboots, enabling offline functionality.
Powerful querying: Supports efficient searches using indexes on various data properties.
Object-oriented: Stores and retrieves JavaScript objects directly, simplifying data manipulation.
Transactions: Ensure data consistency and integrity even with complex operations.

Considerations:

Complexity: Requires more programming effort compared to simpler storage APIs like Web Storage.
Asynchronous nature: All operations are asynchronous, demanding understanding of callback-based programming.
Security: Same-origin principle restricts access to the database, preventing third-party websites from stealing data.
Browser compatibility: While widely supported, older browsers might lack full functionality.

https://web.dev/articles/indexeddb?hl=ko#:~:text=IndexedDB%20is%20a%20low%2Dlevel,larger%20amounts%20of%20structured%20data.

IndexedDB 작업 | Articles | web.dev

IndexedDB의 기본사항에 관한 가이드입니다.

web.dev

https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API

IndexedDB API - Web APIs | MDN

IndexedDB is a low-level API for client-side storage of significant amounts of structured data, including files/blobs. This API uses indexes to enable high-performance searches of this data. While Web Storage is useful for storing smaller amounts of data,

developer.mozilla.org

Nextjs : Edge Functions

ReasonJun — Sun, 7 Jan 2024 00:14:43 +0900

What It Is:

A lightweight, serverless runtime environment designed for executing code closer to users, at the edge of the network.
Built on a subset of standard Web APIs, prioritizing speed, security, and compatibility.
Integrated into Next.js, offering specific features:
- Edge API Routes
- Middleware
- Server components (experimental)

Key Characteristics:

Minimal: Supports a smaller set of APIs compared to the full Node.js runtime.
Fast: Executes code quickly due to its lightweight nature and edge deployment.
Secure: Designed with security in mind, mitigating risks associated with traditional server-side rendering.
Interoperable: Aligns with Web standards for compatibility across environments.

When to Use It:

Low-latency dynamic content: Ideal for delivering personalized content or data with minimal delays.
Simple server-side logic: Well-suited for tasks like authentication, authorization, or simple data fetching.
Global distribution: Optimizes performance and scalability for users worldwide.

Key Features in Next.js:

Edge API Routes: Create API routes that run on the Edge Runtime for fast responses and global distribution.
Middleware: Intercept requests and responses for tasks like authentication or redirects.
Server Components (experimental): Server-side components that can fetch data and render on the Edge Runtime.

Limitations:

Limited API support: Doesn't support all Node.js APIs or globals like require.
Code size restrictions: Deployment platforms often have code size limits for Edge functions.

Best Practices:

Use it for small, fast functions that don't require extensive Node.js APIs.
Prioritize Web APIs and ES modules for compatibility.
Test thoroughly to ensure code functions as expected in the Edge Runtime environment.

https://vercel.com/docs/functions/edge-functions

Edge Functions Overview

Vercel's Edge Functions enable you to deliver dynamic, personalized content with the lightweight Edge Runtime. Learn more about Edge Functions here.

vercel.com

Ethereum : Account structure

ReasonJun — Fri, 5 Jan 2024 18:12:33 +0900

In the case of Bitcoin blockchain, state values are managed based on UTXO. The user's balance is managed by updating the UTXO usage status whenever a new block is created.
In the case of the Ethereum blockchain, the state value of balance data is stored in the Account based on the state, and the balance is updated every time a block is created.

Types of Accounts:

There are two main types of accounts in Ethereum:

Externally Owned Accounts (EOA): These are user-controlled accounts, often accessed through software wallets like MetaMask or MyEtherWallet. EOAs are represented by a public address (derived from the private key) and hold balances in Ether (ETH). They lack their own code and rely on user interaction through private key signatures to initiate transactions.
Contract Accounts: These are accounts created by deploying smart contracts onto the Ethereum Virtual Machine (EVM). They're controlled by the code embedded within the smart contract and can hold balances, execute their programmed functions, and interact with other accounts. Unlike EOAs, they don't have private keys and can't initiate transactions by themselves.

Account Components:

Every account (EOA or contract) consists of several key components:

Address: This is a unique identifier for the account on the Ethereum network, typically represented as a 42-character hexadecimal string. It's derived from the public key of the corresponding key pair.
Balance: This represents the amount of Ether (ETH) held by the account. Any change in balance occurs through transactions (sending or receiving ETH).
Nonce: This is a counter that keeps track of the number of transactions sent from the account. It prevents replay attacks and ensures transaction uniqueness. (0 ~ +1)
StorageRoot: This is the hash value of the root node of the account Merkle Patricia Trie. The default is empty. Used together with Account Storage.
CodeHash: This is the bytecode of the smart contract deployed to the account. It defines the logic and functionality of the contract and determines how it interacts with the Ethereum network. In the case of EOA this is empty.

How to make EOA?

Bitcoin and Ethereum use the same ECDSA Alogorithm. => ECC elliptic curves are also used in the same way. => The same applies to using secp256k1 among elliptic curves. Therefore, if you create an account in Bitcoin and Ethereum with an already created private key, the same address is created.

Private Key => (secp256k1) => Public Key =>. Keccak-256 Hash (Result value lower 20 bytes) => address

How to make CA?

1. Network Deploy

When EOA creates a CA or uses CREATE (OPCODE) on the contract, the network creates and returns an Address in the same manner as the code below.

2. Using CREATE2

Using CREATE2, you can know the Contract Address in advance before network distribution.

Address Checksum

In the case of Ethereum Address, unlike Bitcoin, checksum is not included in the creation process, so it is difficult to check whether the address is accurate. To solve this problem, a checksum function is provided by converting the case of the address through EIP-55.

Ethereum Naming Service (ENS)

Like DNS, it is registered and used in a language that is easy for users to understand. Purchase the name using Smart Contract. This is a function that automatically converts and delivers the name to the address when you enter the name as the recipient in a supported wallet.

Ethereum : Patricia Merkle Tries

ReasonJun — Fri, 5 Jan 2024 17:13:45 +0900

Ethereum uses a Key-Value based DB (leveldb).

By using the hashed value of the address as the key and using the address as the path as shown in the picture on the below, you can find out the state value of the account.

Ethereum Tries

The Tries used in Ethereum are Storage Trie, State Trie, Transaction Trie, and Receipts Trie.
Among these, the Root Hash value stored in the Block Header is State Trie, Transaction Trie, and Receipts Trie.

https://i.stack.imgur.com/afWDt.jpg

What is Ommers?

https://www.investopedia.com/terms/u/uncle-block-cryptocurrency.asp

What Is an Ommer (Uncle) Block in Cryptocurrency?

Ommer blocks are blocks not selected by the Ethereum network to add to the blockchain. Learn more about them and what they do for the network.

www.investopedia.com

Near DNFT Widget

ReasonJun — Tue, 26 Dec 2023 19:13:38 +0900

Product :

https://near.org/near/widget/ComponentDetailsPage?src=7649ed19fe15dead3bb479bbbf3acd3a2b337eead0999673d20b9935e4d60d8e/widget/dNFTMinting

https://near.org/near/widget/ComponentDetailsPage?src=7649ed19fe15dead3bb479bbbf3acd3a2b337eead0999673d20b9935e4d60d8e%2Fwidget%2FdNFTMinting

near.org

Github :

https://github.com/YouJun-IWON/BOS-Contest

GitHub - YouJun-IWON/BOS-Contest

Contribute to YouJun-IWON/BOS-Contest development by creating an account on GitHub.

github.com

Presentation :

https://www.canva.com/design/DAFvPg38fVQ/Rs0eAU30vNFxPhZWCPcSPQ/edit?utm_content=DAFvPg38fVQ&utm_campaign=designshare&utm_medium=link2&utm_source=sharebutton

AAVE Blockchian Report

ReasonJun — Tue, 26 Dec 2023 18:03:44 +0900

Presentation :

https://www.canva.com/design/DAFzlnBpAHg/h1Fkw2wP2vyWb4-aOE-jzw/edit?utm_content=DAFzlnBpAHg&utm_campaign=designshare&utm_medium=link2&utm_source=sharebutton

Report :

https://candle-keyboard-dd4.notion.site/AAVE-eb5cad920ac5457994ca156c046e9419?pvs=4

Real Estate NFT Platform Report (Blockchain At Yonsei STO Research)

ReasonJun — Tue, 26 Dec 2023 17:24:42 +0900

1. Real estate can be bought and sold more efficiently and safely through tokenization of real assets rather than paper title deeds that can be lost or altered. This is because all information is recorded in a distributed ledger, so anyone can track ownership history and previous transactions to verify authenticity.
2. Currently, purchasing real estate takes anywhere from a few weeks to several months, including signing and exchanging a contract, but using NFTs, assets are transferred almost instantly. This is because it can be processed automatically if the conditions are met through a smart contract. It simplifies and speeds up the traditionally slow real estate process.
3. Purchasing real estate with smart contract functionality can trigger a variety of automated actions, including payments, leases, maintenance, dividends, etc.
4. By dividing the real estate deed into NFTs, or tokens, ownership of the real estate deed can be shared by multiple investors. However, partial ownership of this real estate deed is managed in a way that bypasses certain legal areas.
5. Many costs can be saved as the existing real estate transaction process is simplified.

However, no national agency or government has yet recognized real estate NFTs.

So, the current real estate NFT platform is producing and brokering real estate NFTs by tokenizing companies that own real estate.

So, as follows, real estate brokerages through NFT usually consist of real estate companies that own a lot of land and can independently manage real estate-related assets, or blockchain companies that can safely distribute many digital assets. . In other words, it is carried out by real estate companies or blockchain companies that can build a highly reliable financial system under national law.

In common, they have a platform that records real estate records on the blockchain and allows them to be bought and sold using cryptocurrency. Partial ownership is possible through stock purchases or NFT purchases through coins. Some operate with national SEC certification, while others do not and operate on their own.

Its own coins are basically not recognized by external exchanges or banks, but instead enable leverage through decentralized exchanges. There were also places that were operating their own token swaps.

Nextjs Project: Christmas pet ai profile Platform Product / Building Problems

ReasonJun — Tue, 26 Dec 2023 16:59:58 +0900

Product :

https://www.pets-mas.com/

메리 댕냥스마스

우리집 댕냥이로 크리스마스 카드를 만들어 보세요!

www.pets-mas.com

Video :

https://youtu.be/mBvLnZIfWoA

problems :

1. filter routing problem :

=> I set filtering in the layout for each page, but a loop phenomenon was discovered.

2. Libraries that worked normally on desktop did not work on mobile.

3. Depending on the mobile software version, some operations may not work.

4. There were problems with communication between designers and backend, and there was source waste.

5. Problems may occur due to unexpected errors after domain deployment.

6.I proceeded without using the state management library and had a lot of trouble with the data streams of each component.

Solutions :

1. If the page continues to be re-rendered, check to see if there are any cases where a loop may occur in the page layout.

2. Don’t let your guard down just because it worked normally on the desktop, let’s test it on mobile as well.

3. Please note the mobile software version. It is best to avoid using technology that is too cutting-edge.

4. Let’s communicate sufficiently with designers and back-end developers and write specifications.

5. After deploying a domain, you should continuously check operational logs. Let’s make logs and error handling clear about areas where errors may occur.

6. It is best to use the state management library whenever possible. You can receive great help in moving and modifying data.

Nextjs error : cause: Error: unable to verify the first certificate

ReasonJun — Tue, 19 Dec 2023 02:11:32 +0900

Problem :

I'm using Nextjs 14 and wanted to utilize the layout folder to automatically load data when accessing the web.

Why?

This is fine when sending requests from client to server, but when communicating from server to server in Nextjs, the difference between http/https causes problems.

Can occur while the Next.js app is establishing an SSL/TLS secure connection. Typically, this error occurs when there is a problem with the certificate chain. Certificate chaining is about ensuring that the SSL certificate for a particular server is linked to a trusted root certificate.

Possible solutions include

Review the certificate chain: You need to make sure that the certificate is installed correctly. You can use the SSL Validation tool to do this.
Reinstall the certificate: If there was a problem installing the certificate, you need to reinstall the certificate.
Review your server settings: You need to make sure that your server is set up to handle SSL/TLS connections correctly.

https://www.reddit.com/r/nextjs/comments/pniwti/unable_to_verify_the_first_certificate/

From the nextjs community on Reddit: unable to verify the first certificate

Explore this post and more from the nextjs community

www.reddit.com

Solution

https://www.youtube.com/watch?v=Tjw7evZXsLI

NextJS : Type error: Route "src/app/api/auth/[...nextauth]/route.ts" does not match the required types of a Next.js Route. "authOptions" is not a valid Route export field.

ReasonJun — Sat, 16 Dec 2023 01:29:46 +0900

https://codevoweb.com/setup-and-use-nextauth-in-nextjs-13-app-directory/

Setup and Use NextAuth.js in Next.js 13 App Directory - CodevoWeb

In this tutorial, I’ll walk you through setting up authentication in your Next.js 13 app directory using NextAuth.js. It’s worth noting that while we use...

codevoweb.com

https://github.com/vercel/next.js/discussions/50511

Why does my NextAuthJS discord login work in the test environment but cannot be built to production? (NextJS 13) · vercel/next.

Summary I am trying to deploy a NextJS application to vercel. This is a test sign in model using AuthJS. When I run the program using npm run devit works fine and I am able to log in to my discord ...

github.com

React lib : Upload multiple Image using Cloudinary

ReasonJun — Sat, 16 Dec 2023 00:37:58 +0900

upload setting rule :

https://support.cloudinary.com/hc/en-us/articles/202520662-How-can-I-bulk-upload-my-images-

method:

https://cloudinary.com/blog/guest_post/upload-images-with-react-dropzone

Upload Images with React-Dropzone

This post describes how to upload images using the react-dropzone package. We’ll go through the implementation process by building a basic Next.js application that lets us select images and upload them to Cloudinary. We’ll also look at the various ways

cloudinary.com

Next.js Error : Hydration failed because the initail UI does not match what was rendered on the server.

ReasonJun — Thu, 23 Nov 2023 11:19:46 +0900

Error :

Why :

While rendering your application, there was a difference between the React tree that was pre-rendered from the server and the React tree that was rendered during the first render in the browser (hydration).

Solution :

import { useState, useEffect } from 'react'
 
export default function App() {
  const [isClient, setIsClient] = useState(false)
 
  useEffect(() => {
    setIsClient(true)
  }, [])
 
  return <h1>{isClient ? 'This is never prerendered' : 'Prerendered'}</h1>
}

https://nextjs.org/docs/messages/react-hydration-error

Text content does not match server-rendered HTML

Using App Router Features available in /app

nextjs.org

Prisma : Next Auth Google provider error

ReasonJun — Tue, 7 Nov 2023 02:41:31 +0900

When :

When implementing login using prisma and nextauth.

Error message :

[next-auth][error][adapter_error_getUserByAccount]
https://next-auth.js.org/errors#adapter_error_getuserbyaccount
Invalid `prisma.account.findUnique()` invocation:

prisma code :

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider     = "mysql"
  url          = env("DATABASE_URL")
  // Add this
  relationMode = "prisma"
}

model Account {
  id                String  @id @default(cuid())
  userId            String
  type              String
  provider          String
  providerAccountId String
  refresh_token     String? @db.Text
  access_token      String? @db.Text
  expires_at        Int?
  token_type        String?
  scope             String?
  id_token          String? @db.Text
  session_state     String?
  user              User    @relation(fields: [userId], references: [id], onDelete: Cascade)

  @@unique([provider, providerAccountId])
  @@index([userId], map: "Account_userId_fkey")
}

model Session {
  id           String   @id @default(cuid())
  sessionToken String   @unique
  userId       String
  expires      DateTime
  user         User     @relation(fields: [userId], references: [id], onDelete: Cascade)

  @@index([userId], map: "Session_userId_fkey")
}

model User {
  id             String          @id @default(cuid())
  name           String?
  email          String?         @unique
  emailVerified  DateTime?
  active         Boolean         @default(false)
  image          String?
  role           String?
  hashedPassword String?
  userType       UserType        @default(User)
  accounts       Account[]
  sessions       Session[]
  ActivateToken  ActivateToken[]
}

model ActivateToken {
  id    String @id @default(cuid())
  token String @unique

  activatedAt DateTime?
  createdAt   DateTime  @default(now())
  updatedAt   DateTime  @updatedAt

  user   User   @relation(fields: [userId], references: [id])
  userId String

  @@index([userId])
}

enum UserType {
  User
  Admin
  Youtuber
}

model VerificationToken {
  identifier String
  token      String   @unique
  expires    DateTime

  @@unique([identifier, token])
}

Solution : remove 'map: "~~~"'

Why ?

In the Prisma schema code you provided, the line @@index([userId], map: "Account_userId_fkey") is defining an index for the "Account" model. Let's break down what this line means:

@@index: This is a Prisma schema decorator that is used to define an index on the database table associated with the "Account" model. Indexes are used to optimize database query performance by allowing faster lookup and retrieval of rows based on the indexed columns.
([userId], map: "Account_userId_fkey"): This part of the code specifies the index definition. It consists of two components:
- ([userId]): This is an array of column names on which the index is defined. In this case, the index is defined on the "userId" column of the "Account" model. This means that the database will create an index on the "userId" column, which will improve query performance for operations that involve searching or filtering by the "userId" column.
- map: "Account_userId_fkey": The map option provides a name for the index. In this case, the index is named "Account_userId_fkey." This name is typically used as a reference when working with the database, and it helps in uniquely identifying the index.

In summary, the @@index decorator in your Prisma schema is creating an index on the "userId" column of the "Account" model to improve query performance when searching or filtering records based on the "userId" value. The name of the index is specified as "Account_userId_fkey."

For this reason, 'findUnique' of the account could not be found.

Nextjs : Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension. (ts-node)

ReasonJun — Mon, 6 Nov 2023 13:50:28 +0900

What happened?

In the case of ts-node, ts was compiled using the commonJS method. Therefore, an error occurs when you try to run a ts file with ts-node in the app or src subfolder of nextjs, which is compiled with esNext.

Error :

https://github.com/TypeStrong/ts-node/issues/935

`ts-node` fails when ES Modules are in the dependency graph in Node.js 13+ · Issue #935 · TypeStrong/ts-node

I basically detailed the issue in this comment: #155 (comment) It's a chicken-and-egg-like problem: If we use module: 'commonjs', then if any TS files import ES Modules (indirectly in their depende...

github.com

Solution :

https://www.npmjs.com/package/ts-node?activeTab=readme#commonjs

ts-node

TypeScript execution environment and REPL for node.js, with source map support. Latest version: 10.9.1, last published: a year ago. Start using ts-node in your project by running `npm i ts-node`. There are 9079 other projects in the npm registry using ts-n

www.npmjs.com

https://stackoverflow.com/questions/69870137/running-a-single-ts-file-in-a-next-js-project-with-ts-node-for-testing

Running a single .ts file in a Next.js project with ts-node for testing

I'm trying to run a single ES module .ts file in a Next.js project with default config for quick debugging: npx ts-node lib/my_module.ts which gives me this error: Warning: To load an ES module, s...

stackoverflow.com

Typescript : Zod

ReasonJun — Fri, 3 Nov 2023 00:48:32 +0900

https://www.daleseo.com/zod-schema/

Zod를 통한 타입스크립트 친화적인 스키마 정의

Engineering Blog by Dale Seo

www.daleseo.com

Tailwindcss : twMerge, clsx

ReasonJun — Wed, 1 Nov 2023 17:26:54 +0900

twMerge is a JavaScript library that merges Tailwind CSS classes without style conflicts. It is useful when you need to conditionally join Tailwind CSS classes together, or when you need to merge Tailwind CSS classes from different sources.

clsx is a JavaScript library that provides a simple and efficient way to conditionally join CSS classes together. It is useful for creating reusable CSS components and for writing complex CSS rules.

Using twMerge and clsx together

You can use twMerge and clsx together to create a powerful and flexible way to manage Tailwind CSS classes in JavaScript. For example, you can create a utility function that merges Tailwind CSS classes and resolves any conflicts:

import { ClassValue, clsx } from 'clsx';
import { twMerge } from 'tailwind-merge';

export const cn = (...inputs: ClassValue[]) => {
  return twMerge(clsx(inputs));
};

This function takes any number of CSS classes as input and returns a single CSS class string that is merged and conflict-free. You can then use this function in your React components to conditionally join Tailwind CSS classes together:

import React from 'react';
import { cn } from './cn';

const Button = ({ variant, size, children }) => {
  return (
    <button className={cn({ variant, size })}>
      {children}
    </button>
  );
};

export default Button;

This component will render a button with the specified variant and size. The cn() function will merge the variant and size classes together and resolve any conflicts.

Benefits of using twMerge and clsx together

There are several benefits to using twMerge and clsx together:

Efficiency: twMerge and clsx are both very efficient libraries. This means that you can merge and conditionally join Tailwind CSS classes without any noticeable performance overhead.
Flexibility: twMerge and clsx give you a lot of flexibility in how you manage Tailwind CSS classes in JavaScript. You can create your own utility functions and components to meet your specific needs.
Consistency: Using twMerge and clsx together can help to ensure that your code is consistent and easy to read.

Overall, twMerge and clsx are two powerful libraries that can help you to write more efficient, flexible, and consistent Tailwind CSS code.

https://www.youtube.com/watch?v=re2JFITR7TI

Solidity : 0.8.20 PUSH0 ( invalid opcode )

ReasonJun — Mon, 23 Oct 2023 14:19:46 +0900

the new PUSH0 opcode in Solidity 0.8.20. It discusses what the opcode is and why it is needed. It also goes into the benefits of using PUSH0, such as reducing contract size and gas costs. Finally, the article provides a warning about using PUSH0 on other chains besides Ethereum mainnet.

Here is a more detailed summary of the article:

PUSH0 is a new opcode in Solidity 0.8.20 that allows developers to push an empty byte string onto the stack.
This is useful for a variety of reasons, such as initializing arrays and structs, and for passing empty arguments to functions.
PUSH0 can also be used to reduce contract size and gas costs, as it can eliminate the need to store empty byte strings in the contract code.
However, it is important to note that PUSH0 should not be used on other chains besides Ethereum mainnet, as it is not supported by all compilers and runtimes.

https://medium.com/coinmonks/push0-opcode-a-significant-update-in-the-latest-solidity-version-0-8-20-ea028668028a

PUSH0 opcode: A significant update in the latest solidity version 0.8.20

What is the PUSH0 opcode? An explanation of solidity latest version 0.8.20 changes and EIP-3855.

medium.com

https://eips.ethereum.org/EIPS/eip-3855?ref=zaryabs.com

EIP-3855: PUSH0 instruction

Introduce a new instruction which pushes the constant value 0 onto the stack

eips.ethereum.org

Solidity : abi.encodePacked(), super.uri()

ReasonJun — Sun, 22 Oct 2023 22:06:38 +0900

The abi.encodePacked() function is a built-in Solidity function that is used to encode multiple values into a single byte array. The function takes any number of arguments and concatenates them into a single byte array.

The abi.encodePacked() function is typically used to encode data that is going to be passed to a contract function. For example, the following code would encode the string "Hello, world!" into a byte array:

bytes memory data = abi.encodePacked("Hello, world!");

The data variable would now contain the byte array [0x48, 0x65, 0x6c, 0x6c, 0x6f, 0x2c, 0x20, 0x77, 0x6f, 0x72, 0x6c, 0x64, 0x21].

The abi.encodePacked() function can also be used to encode multiple values into a single byte array. For example, the following code would encode the values 1, 2, and 3 into a single byte array:

bytes memory data = abi.encodePacked(1, 2, 3);

The data variable would now contain the byte array [0x01, 0x02, 0x03].

The abi.encodePacked() function is a useful function for encoding data that is going to be passed to a contract function. The function can be used to encode any type of data, including strings, integers, and booleans.

function uri(uint256 tokenId) public view virtual override returns (string memory) {
        string memory tokenURI = _tokenURIs[tokenId];

        // If token URI is set, concatenate base URI and tokenURI (via abi.encodePacked).
        return bytes(tokenURI).length > 0 ? string(abi.encodePacked(_baseURI, tokenURI)) : super.uri(tokenId);
    }

The code string(abi.encodePacked(_baseURI, tokenURI)) is used to cast the byte array returned by the abi.encodePacked() function to a string. The abi.encodePacked() function takes two arguments, _baseURI and tokenURI, and concatenates them into a single byte array. The string() function then casts the byte array to a string.

The resulting string is the token URI for the token. The token URI is a JSON document that contains information about the token, such as its name, description, and image.

The token URI is used by OpenSea and other NFT marketplaces to display information about the token.

In this case, the _baseURI is the base URI for all tokens. The base URI is a string that is used to generate the token URI for a token. For example, if the base URI is https://example.com/tokens/, then the token URI for token ID 1 would be https://example.com/tokens/1.

The tokenURI is the token URI for a specific token. The token URI can be set using the setURI() function.

For example, if the tokenURI for token ID 1 is { "name": "My Token", "description": "This is my token.", "image": "<https://example.com/tokens/1.jpg>" }, then the resulting string would be:

"https://example.com/tokens/{ "name": "My Token", "description": "This is my token.", "image": "https://example.com/tokens/1.jpg" }"

super.uri()

In the context of the MyERC1155 contract, the super.uri(tokenId) function is used to generate the token URI for a token if a token URI has not been set for the token. The MyERC1155 contract has a setURI() function that can be used to set a token URI for a specific token.

If a token URI has been set for a token, then the MyERC1155 contract will return the token URI that was set. Otherwise, the MyERC1155 contract will call the super.uri(tokenId) function to generate the token URI.

The super.uri(tokenId) function is a useful function for ensuring that all tokens have a token URI. The token URI is used by OpenSea and other NFT marketplaces to display information about the token.

Ethereum : ERC1155

ReasonJun — Sun, 22 Oct 2023 21:29:08 +0900

ERC-1155 is a token standard for representing both fungible and non-fungible tokens (NFTs) on the Ethereum blockchain. It is a single standard that can be used to represent a wide variety of assets, such as game items, collectibles, and even real-world assets.

ERC-1155 tokens are identified by two values: a token ID and a balance. The token ID is a unique identifier for the type of token, while the balance is the amount of that type of token that an address holds. For example, an ERC-1155 token could represent a game item, such as a sword. The token ID would be the same for all swords, but the balance would be different for each address that holds swords.

ERC-1155 tokens can be both fungible and non-fungible. Fungible tokens are interchangeable, meaning that one token is worth the same as any other token of the same type. For example, ERC-20 tokens are fungible, as one Ether (ETH) is worth the same as any other ETH. Non-fungible tokens are not interchangeable, meaning that each token is unique. For example, an ERC-721 token that represents a collectible artwork is non-fungible, as no two artworks are exactly alike.

ERC-1155 tokens offer a number of advantages over other token standards. First, they are more efficient, as they can be used to represent a wider variety of assets. Second, they are more flexible, as they can be both fungible and non-fungible. Third, they are more secure, as they are less likely to be subject to fraud or manipulation.

ERC-1155 tokens are a powerful tool that can be used to create a wide variety of decentralized applications (dApps). They are a versatile standard that can be used to represent a wide range of assets, and they offer a number of advantages over other token standards.

Here are some of the benefits of using ERC-1155 tokens:

Efficiency: ERC-1155 tokens are more efficient than other token standards, as they can be used to represent a wider variety of assets. For example, a single ERC-1155 contract could be used to represent all of the items in a game, such as weapons, armor, and potions. This would save gas and storage space, as it would not be necessary to create a separate contract for each item.
Flexibility: ERC-1155 tokens are more flexible than other token standards, as they can be both fungible and non-fungible. This makes them ideal for representing a wide range of assets. For example, an ERC-1155 token could be used to represent both fungible assets, such as game currency, and non-fungible assets, such as unique game items.
Security: ERC-1155 tokens are more secure than other token standards, as they are less likely to be subject to fraud or manipulation. This is because ERC-1155 tokens use a more robust approval mechanism than other token standards.

Overall, ERC-1155 tokens are a powerful tool that can be used to create a wide variety of dApps. They are a versatile standard that can be used to represent a wide range of assets, and they offer a number of advantages over other token standards.

Feature	ERC-721	ERC-1155
Fungibility	Non-fungible	Fungible and non-fungible
Token ID	Single token ID per token type	Single token ID for all tokens of the same type
Balance	Balance is not tracked	Balance is tracked for each token type
Use cases	Collectibles, digital art, game items	Game items, in-game currency, tickets, voting rights
Examples	CryptoKitties, Decentraland, NBA Top Shot	Enjin Coin, Gods Unchained, Decentraland
Efficiency	Less efficient, as a separate contract is required for each token type	More efficient, as a single contract can be used to represent multiple token types
Flexibility	Less flexible, as tokens can only be non-fungible	More flexible, as tokens can be both fungible and non-fungible
Security	More secure, as the approval mechanism is more robust	Less secure, as the approval mechanism is less robust

Openzeppelin : ERC20PresetMinterPauser

ReasonJun — Sun, 22 Oct 2023 21:06:49 +0900

// SPDX-License-Identifier: MIT
// OpenZeppelin Contracts (last updated v4.5.0) (token/ERC20/presets/ERC20PresetMinterPauser.sol)

pragma solidity ^0.8.0;

import "../ERC20.sol";
import "../extensions/ERC20Burnable.sol";
import "../extensions/ERC20Pausable.sol";
import "../../../access/AccessControlEnumerable.sol";
import "../../../utils/Context.sol";

/**
 * @dev {ERC20} token, including:
 *
 *  - ability for holders to burn (destroy) their tokens
 *  - a minter role that allows for token minting (creation)
 *  - a pauser role that allows to stop all token transfers
 *
 * This contract uses {AccessControl} to lock permissioned functions using the
 * different roles - head to its documentation for details.
 *
 * The account that deploys the contract will be granted the minter and pauser
 * roles, as well as the default admin role, which will let it grant both minter
 * and pauser roles to other accounts.
 *
 * _Deprecated in favor of https://wizard.openzeppelin.com/[Contracts Wizard]._
 */
contract ERC20PresetMinterPauser is Context, AccessControlEnumerable, ERC20Burnable, ERC20Pausable {
    bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");
    bytes32 public constant PAUSER_ROLE = keccak256("PAUSER_ROLE");

    /**
     * @dev Grants `DEFAULT_ADMIN_ROLE`, `MINTER_ROLE` and `PAUSER_ROLE` to the
     * account that deploys the contract.
     *
     * See {ERC20-constructor}.
     */
    constructor(string memory name, string memory symbol) ERC20(name, symbol) {
        _setupRole(DEFAULT_ADMIN_ROLE, _msgSender());

        _setupRole(MINTER_ROLE, _msgSender());
        _setupRole(PAUSER_ROLE, _msgSender());
    }

    /**
     * @dev Creates `amount` new tokens for `to`.
     *
     * See {ERC20-_mint}.
     *
     * Requirements:
     *
     * - the caller must have the `MINTER_ROLE`.
     */
    function mint(address to, uint256 amount) public virtual {
        require(hasRole(MINTER_ROLE, _msgSender()), "ERC20PresetMinterPauser: must have minter role to mint");
        _mint(to, amount);
    }

    /**
     * @dev Pauses all token transfers.
     *
     * See {ERC20Pausable} and {Pausable-_pause}.
     *
     * Requirements:
     *
     * - the caller must have the `PAUSER_ROLE`.
     */
    function pause() public virtual {
        require(hasRole(PAUSER_ROLE, _msgSender()), "ERC20PresetMinterPauser: must have pauser role to pause");
        _pause();
    }

    /**
     * @dev Unpauses all token transfers.
     *
     * See {ERC20Pausable} and {Pausable-_unpause}.
     *
     * Requirements:
     *
     * - the caller must have the `PAUSER_ROLE`.
     */
    function unpause() public virtual {
        require(hasRole(PAUSER_ROLE, _msgSender()), "ERC20PresetMinterPauser: must have pauser role to unpause");
        _unpause();
    }

    function _beforeTokenTransfer(
        address from,
        address to,
        uint256 amount
    ) internal virtual override(ERC20, ERC20Pausable) {
        super._beforeTokenTransfer(from, to, amount);
    }
}

This is the source code for the ERC20PresetMinterPauser contract. This contract is a preset implementation of the ERC-20 standard that includes the following features:

The ability for holders to burn (destroy) their tokens
A minter role that allows for token minting (creation)
A pauser role that allows to stop all token transfers

The contract uses the AccessControl library to lock permissioned functions using the different roles. The account that deploys the contract will be granted the minter and pauser roles, as well as the default admin role, which will let it grant both minter and pauser roles to other accounts.

The mint() function mints a new token and assigns it to the specified address. The caller must have the MINTER_ROLE in order to call this function.

The pause() and unpause() functions pause and unpause all token transfers, respectively. The caller must have the PAUSER_ROLE in order to call these functions.

The _beforeTokenTransfer() function is called before any token transfer. This function is used to implement the pausable functionality. If the contract is paused, then the transfer will be cancelled.

The supportsInterface() function returns true if the contract supports the specified interface. The contract supports the following interfaces:

IERC165
IERC20
IERC20Metadata
AccessControlEnumerable

This contract is a good starting point for anyone who wants to create an ERC-20 token with the features listed above.

Openzeppelin : ERC721PresetMinterPauserAutoId

ReasonJun — Sun, 22 Oct 2023 21:01:48 +0900

// SPDX-License-Identifier: MIT
// OpenZeppelin Contracts (last updated v4.8.0) (token/ERC721/presets/ERC721PresetMinterPauserAutoId.sol)

pragma solidity ^0.8.0;

import "../ERC721.sol";
import "../extensions/ERC721Enumerable.sol";
import "../extensions/ERC721Burnable.sol";
import "../extensions/ERC721Pausable.sol";
import "../../../access/AccessControlEnumerable.sol";
import "../../../utils/Context.sol";
import "../../../utils/Counters.sol";

/**
 * @dev {ERC721} token, including:
 *
 *  - ability for holders to burn (destroy) their tokens
 *  - a minter role that allows for token minting (creation)
 *  - a pauser role that allows to stop all token transfers
 *  - token ID and URI autogeneration
 *
 * This contract uses {AccessControl} to lock permissioned functions using the
 * different roles - head to its documentation for details.
 *
 * The account that deploys the contract will be granted the minter and pauser
 * roles, as well as the default admin role, which will let it grant both minter
 * and pauser roles to other accounts.
 *
 * _Deprecated in favor of https://wizard.openzeppelin.com/[Contracts Wizard]._
 */
contract ERC721PresetMinterPauserAutoId is
    Context,
    AccessControlEnumerable,
    ERC721Enumerable,
    ERC721Burnable,
    ERC721Pausable
{
    using Counters for Counters.Counter;

    bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");
    bytes32 public constant PAUSER_ROLE = keccak256("PAUSER_ROLE");

    Counters.Counter private _tokenIdTracker;

    string private _baseTokenURI;

    /**
     * @dev Grants `DEFAULT_ADMIN_ROLE`, `MINTER_ROLE` and `PAUSER_ROLE` to the
     * account that deploys the contract.
     *
     * Token URIs will be autogenerated based on `baseURI` and their token IDs.
     * See {ERC721-tokenURI}.
     */
    constructor(
        string memory name,
        string memory symbol,
        string memory baseTokenURI
    ) ERC721(name, symbol) {
        _baseTokenURI = baseTokenURI;

        _setupRole(DEFAULT_ADMIN_ROLE, _msgSender());

        _setupRole(MINTER_ROLE, _msgSender());
        _setupRole(PAUSER_ROLE, _msgSender());
    }

    function _baseURI() internal view virtual override returns (string memory) {
        return _baseTokenURI;
    }

    /**
     * @dev Creates a new token for `to`. Its token ID will be automatically
     * assigned (and available on the emitted {IERC721-Transfer} event), and the token
     * URI autogenerated based on the base URI passed at construction.
     *
     * See {ERC721-_mint}.
     *
     * Requirements:
     *
     * - the caller must have the `MINTER_ROLE`.
     */
    function mint(address to) public virtual {
        require(hasRole(MINTER_ROLE, _msgSender()), "ERC721PresetMinterPauserAutoId: must have minter role to mint");

        // We cannot just use balanceOf to create the new tokenId because tokens
        // can be burned (destroyed), so we need a separate counter.
        _mint(to, _tokenIdTracker.current());
        _tokenIdTracker.increment();
    }

    /**
     * @dev Pauses all token transfers.
     *
     * See {ERC721Pausable} and {Pausable-_pause}.
     *
     * Requirements:
     *
     * - the caller must have the `PAUSER_ROLE`.
     */
    function pause() public virtual {
        require(hasRole(PAUSER_ROLE, _msgSender()), "ERC721PresetMinterPauserAutoId: must have pauser role to pause");
        _pause();
    }

    /**
     * @dev Unpauses all token transfers.
     *
     * See {ERC721Pausable} and {Pausable-_unpause}.
     *
     * Requirements:
     *
     * - the caller must have the `PAUSER_ROLE`.
     */
    function unpause() public virtual {
        require(hasRole(PAUSER_ROLE, _msgSender()), "ERC721PresetMinterPauserAutoId: must have pauser role to unpause");
        _unpause();
    }

    function _beforeTokenTransfer(
        address from,
        address to,
        uint256 firstTokenId,
        uint256 batchSize
    ) internal virtual override(ERC721, ERC721Enumerable, ERC721Pausable) {
        super._beforeTokenTransfer(from, to, firstTokenId, batchSize);
    }

    /**
     * @dev See {IERC165-supportsInterface}.
     */
    function supportsInterface(bytes4 interfaceId)
        public
        view
        virtual
        override(AccessControlEnumerable, ERC721, ERC721Enumerable)
        returns (bool)
    {
        return super.supportsInterface(interfaceId);
    }
}

This is the source code for the ERC721PresetMinterPauserAutoId contract. This contract is a preset implementation of the ERC-721 standard that includes the following features:

The ability for holders to burn (destroy) their tokens
A minter role that allows for token minting (creation)
A pauser role that allows to stop all token transfers
Token ID and URI autogeneration

The _baseURI() function returns the base URI for all token URIs. The base URI is the prefix that is added to the token ID to generate the full token URI. For example, if the base URI is https://example.com/tokens/, then the token URI for token ID 1 would be https://example.com/tokens/1.

The mint() function mints a new token and assigns it to the specified address. The token ID is automatically assigned and the token URI is generated based on the base URI. The caller must have the MINTER_ROLE in order to call this function.

The pause() and unpause() functions pause and unpause all token transfers, respectively. The caller must have the PAUSER_ROLE in order to call these functions.

The _beforeTokenTransfer() function is called before any token transfer. This function is used to implement the pausable functionality. If the contract is paused, then the transfer will be cancelled.

The supportsInterface() function returns true if the contract supports the specified interface. The contract supports the following interfaces:

IERC165
IERC721
IERC721Enumerable
IERC721Metadata
AccessControlEnumerable

This contract is a good starting point for anyone who wants to create an ERC-721 token with the features listed above.

Ethereum : ERC721

ReasonJun — Sun, 22 Oct 2023 20:55:04 +0900

ERC-721 is a standard for non-fungible tokens (NFTs) on the Ethereum blockchain. NFTs are unique digital assets that cannot be replicated or replaced. This is in contrast to fungible tokens, such as ERC-20 tokens, which are interchangeable and can be replaced with one another.

ERC-721 tokens are often used to represent digital collectibles, such as artwork, music, or game items. They can also be used to represent real-world assets, such as property or ownership rights.

The ERC-721 standard defines a set of functions that must be implemented by all ERC-721 tokens. These functions allow for the creation, transfer, and ownership of NFTs.

Some of the key functions in the ERC-721 standard include:

balanceOf(address owner): Returns the balance of the owner's account.
ownerOf(uint256 tokenId): Returns the address of the owner of the given token ID.
transferFrom(address from, address to, uint256 tokenId): Transfers the ownership of the given token ID from the from address to the to address.
approve(address to, uint256 tokenId): Approves the to address to transfer the ownership of the given token ID on behalf of the owner.
setApprovalForAll(address operator, bool approved): Approves the operator address to transfer any of the owner's tokens on their behalf.

The ERC-721 standard is a widely used standard for NFTs. It is supported by most Ethereum wallets and exchanges.

Some of the benefits of using ERC-721 tokens include:

Uniqueness: ERC-721 tokens are unique and cannot be replicated or replaced. This makes them ideal for representing digital collectibles and other unique assets.
Provable ownership: The ownership of ERC-721 tokens is stored on the Ethereum blockchain. This makes it possible to prove ownership of an NFT.
Transferability: ERC-721 tokens can be transferred between addresses. This makes them easy to buy, sell, or trade.

The ERC-721 standard is a powerful tool for creating and managing digital assets. It is a versatile standard that can be used for a wide variety of applications.

Essential function

Essential event

Etherscan : Verify

ReasonJun — Sat, 21 Oct 2023 23:18:15 +0900

In Etherscan, "Verify" is a process that allows developers to upload the source code of their smart contracts to the Etherscan website. Once the source code is uploaded, Etherscan will match it with the bytecode that is deployed on the Ethereum blockchain. If the source code and bytecode match, the contract will be verified.

Verifying a contract has several benefits:

It provides transparency for users interacting with the contract. By uploading the source code, developers are making it possible for users to see how the contract works. This can help to build trust and confidence in the contract.
It allows users to analyze the contract. Once the source code is uploaded, users can use Etherscan's tools to analyze the contract. This can help users to identify potential vulnerabilities or problems with the contract.
It makes it easier to interact with the contract. Once a contract is verified, Etherscan will generate a user interface that makes it easier for users to interact with the contract. This can be helpful for users who are not familiar with how to interact with smart contracts.

To verify a contract, developers can follow these steps:

Go to the Etherscan website.
Click on the "Verify Contract" tab.
Enter the contract address in the "Contract Address" field.
Select the compiler type in the "Compiler Type" field.
Upload the source code in the "Source Code" field.
Click on the "Verify and Publish" button.

If the verification is successful, the contract will be marked as verified on Etherscan.

Hardhat : ethereum-waffle

ReasonJun — Sat, 21 Oct 2023 23:15:36 +0900

Ethereum-Waffle is a testing framework for Ethereum smart contracts. It is designed to be easy to use and to provide a comprehensive set of features for testing smart contracts.

Waffle provides the following features:

A simple and intuitive API for writing tests
Support for all of the Solidity features
A built-in mocking framework
A built-in snapshotting framework
A built-in coverage reporting framework

Waffle is a popular choice for testing Ethereum smart contracts. It is used by many projects, including Uniswap, Aave, and Yearn Finance.

Waffle is a great choice for testing Ethereum smart contracts because it is easy to use and provides a comprehensive set of features. It is also a well-maintained project with a large community of users.

Here are some of the benefits of using Waffle:

Easy to use: Waffle has a simple and intuitive API that makes it easy to write tests.
Comprehensive: Waffle provides support for all of the Solidity features, so you can be sure that your tests are covering all of the code in your smart contracts.
Built-in mocking: Waffle has a built-in mocking framework that makes it easy to mock external dependencies. This can be helpful for testing code that interacts with other contracts or with the Ethereum network.
Built-in snapshotting: Waffle has a built-in snapshotting framework that makes it easy to revert the state of the Ethereum blockchain to a previous point in time. This can be helpful for testing code that modifies the state of the blockchain.
Built-in coverage reporting: Waffle has a built-in coverage reporting framework that makes it easy to see which parts of your code are being covered by your tests.

https://ethereum-waffle.readthedocs.io/en/latest/

Waffle Documentation — waffle documentation

ethereum-waffle.readthedocs.io

Hardhat : ethers.constants.AddressZero

ReasonJun — Sat, 21 Oct 2023 18:18:52 +0900

The ethers.constants.AddressZero constant is a special address that represents the null address. This address is used to represent the address of the contract that is creating tokens.

The null address is a special address that is not associated with any account. It is used to represent the absence of an address. For example, if a token is transferred to the null address, the token is effectively burned.

The null address is also used to represent the address of the contract that is creating tokens. This is because the contract itself does not have an address. When a contract creates tokens, the tokens are created with the address of the contract. However, the contract itself does not have an address, so the null address is used instead.

The ethers.constants.AddressZero constant is a convenient way to refer to the null address. It is also a safe way to refer to the null address, as it is guaranteed to be the correct address.

In the example you provided, the ethers.constants.AddressZero constant is being used to assert that the Transfer event is being emitted with the address of the contract as the sender. This is because the contract is creating the tokens that are being transferred.

Hardhat : ethers.utils.parseUnits()

ReasonJun — Sat, 21 Oct 2023 18:07:38 +0900

ethers.utils.parseUnits() is a utility function provided by the ethers.js library, which is commonly used for Ethereum development. This function is used to convert a decimal number into its equivalent representation in a specific Ethereum denomination, typically in Wei.

In Ethereum, the smallest unit of Ether is Wei. 1 Ether is equal to 10^18 Wei. So, when working with Ether values, it's common to convert them to Wei for precision. The parseUnits() function simplifies this conversion.

Here's the basic usage of ethers.utils.parseUnits():

const ethers = require('ethers'); // Import the ethers.js library

// Example: Convert 1.5 Ether to Wei
const etherValue = '1.5'; // This is in Ether
const weiValue = ethers.utils.parseUnits(etherValue, 18); // 18 is the number of decimal places in Wei

console.log(weiValue.toString()); // This will output the equivalent value in Wei

In the example above, ethers.utils.parseUnits() takes the value 1.5 and converts it to its equivalent in Wei, considering 18 decimal places. The result is then represented as a BigNumber in ethers.js.

This function is useful when working with Ethereum values, especially in smart contract development, where precise conversions between different denominations (Wei, Gwei, Ether, etc.) are often required.

Ethereum : ERC-20 (Ethereum Request for Comments 20)

ReasonJun — Fri, 20 Oct 2023 23:11:25 +0900

ERC-20 is a technical standard for fungible tokens on the Ethereum blockchain. Fungible tokens are interchangeable with each other, meaning that one token is worth the same as any other token of the same type. This is in contrast to non-fungible tokens (NFTs), which are unique and cannot be replaced.

The ERC-20 standard defines a set of rules that all ERC-20 tokens must follow. These rules include:

The ability to transfer tokens from one account to another
The ability to get the current balance of an account
The ability to get the total supply of tokens
The ability to approve an allowance for a third party to spend tokens on behalf of the owner

The ERC-20 standard is widely used, and most Ethereum wallets and exchanges support ERC-20 tokens. This makes it easy to create and trade ERC-20 tokens.

Some of the benefits of using ERC-20 tokens include:

Interoperability: ERC-20 tokens can be used with any wallet or exchange that supports the standard. This makes it easy to move tokens between different platforms.
Liquidity: ERC-20 tokens are widely traded, which makes it easy to buy and sell them.
Flexibility: ERC-20 tokens can be used for a variety of purposes, such as representing assets, voting rights, or access to services.

Some of the most popular ERC-20 tokens include:

Tether (USDT)
USD Coin (USDC)
Binance USD (BUSD)
Dai (DAI)
Chainlink (LINK)

ERC-20 is a valuable standard for creating and using tokens on the Ethereum blockchain. It provides a set of rules that ensure that tokens are interoperable and fungible. This makes it easy to create and trade tokens, and it helps to ensure that tokens are widely accepted.

Essential function

Essential event

Solidity : sol2uml

ReasonJun — Fri, 20 Oct 2023 17:38:10 +0900

Sol2uml is a tool that can be used to generate UML (Unified Modeling Language) diagrams from Solidity smart contracts. UML is a standard language for modeling software systems. By generating UML diagrams from Solidity smart contracts, developers can better understand the structure and design of their contracts.

Sol2uml works by parsing the Solidity code and extracting information about the classes, interfaces, and relationships between them. This information is then used to generate UML class diagrams and storage layout diagrams.

The benefits of using sol2uml include:

Improved understanding of smart contract design: By generating UML diagrams from Solidity smart contracts, developers can better understand the structure and design of their contracts. This can help to identify potential problems with the design and make changes to improve the design.
Increased communication with stakeholders: UML diagrams are a standard way of communicating software design. By generating UML diagrams from Solidity smart contracts, developers can more easily communicate the design of their contracts to stakeholders who are not familiar with Solidity.
Improved documentation: UML diagrams can be used to document the design of Solidity smart contracts. This can help to ensure that the design of the contracts is well-understood and that the contracts are maintainable.

Overall, sol2uml is a valuable tool that can be used to improve the design, communication, and documentation of Solidity smart contracts.

Here are some of the features of sol2uml:

Generates UML class diagrams and storage layout diagrams from Solidity smart contracts
Supports the latest Solidity syntax
Can be used to generate diagrams for individual contracts or entire projects
Can be used to generate diagrams for both deployed and undeployed contracts

If you are developing Solidity smart contracts, then I encourage you to use sol2uml to improve the design, communication, and documentation of your contracts.

Hardhat : hardhat-gas-reporter

ReasonJun — Fri, 20 Oct 2023 17:28:52 +0900

Hardhat-gas-reporter is a plugin for the Hardhat testing framework that can be used to measure the gas usage of Solidity smart contracts. Gas is a unit of measurement for the computational effort required to execute specific operations on the Ethereum blockchain. By measuring the gas usage of a smart contract, developers can identify areas of the code that are consuming a lot of gas and make changes to optimize the code.

Hardhat-gas-reporter works by instrumenting the Solidity code with gas probes. These probes are inserted into the code at strategic points, and they are used to track the gas usage of each line of code. The gas data is then collected and used to generate a report that shows the gas usage for each function in the contract.

The benefits of using hardhat-gas-reporter include:

Improved code optimization: By identifying areas of the code that are consuming a lot of gas, hardhat-gas-reporter can help developers to optimize the code and reduce the gas costs.
Reduced deployment costs: By optimizing the code, developers can reduce the amount of gas that is required to deploy the contract. This can lead to significant savings in deployment costs.
Increased understanding of gas usage: By providing information about the gas usage of each line of code, hardhat-gas-reporter can help developers to better understand how gas is used in Solidity smart contracts.

Overall, hardhat-gas-reporter is a valuable tool that can be used to improve the efficiency of Solidity smart contracts.

Here are some of the features of hardhat-gas-reporter:

Supports multiple testing frameworks, such as Mocha and Hardhat
Generates gas reports for both unit tests and integration tests
Can be used to measure the gas usage of individual functions or entire contracts
Provides detailed information about the gas usage of each line of code
Can be used to identify areas of the code that are consuming a lot of gas

If you are developing Solidity smart contracts, then I encourage you to use hardhat-gas-reporter to improve the efficiency of your code.

Hardhat : Solidity-coverage

ReasonJun — Fri, 20 Oct 2023 17:05:24 +0900

Solidity-coverage is a tool that can be used to measure the code coverage of Solidity smart contracts. Code coverage is a measure of how much of the code in a program has been executed. This can be used to identify areas of the code that are not being tested, and to improve the quality of the test suite.

Solidity-coverage works by instrumenting the Solidity code with coverage probes. These probes are inserted into the code at strategic points, and they are used to track which lines of code have been executed. The coverage data is then collected and used to generate a report that shows the code coverage for the contract.

Solidity-coverage can be used with a variety of testing frameworks, such as Mocha and Hardhat. It can also be used to generate coverage reports for both unit tests and integration tests.

The benefits of using solidity-coverage include:

Improved test quality: By identifying areas of the code that are not being tested, solidity-coverage can help to improve the quality of the test suite.
Reduced debugging time: By providing information about which lines of code have been executed, solidity-coverage can help to reduce the time it takes to debug failing tests.
Increased confidence in the codebase: By showing how much of the code has been tested, solidity-coverage can help to increase confidence in the codebase.

Overall, solidity-coverage is a valuable tool that can be used to improve the quality of Solidity smart contracts.

Here are some of the features of solidity-coverage:

Supports multiple testing frameworks, such as Mocha and Hardhat
Generates coverage reports for both unit tests and integration tests
Can be used to measure the coverage of individual contracts or entire projects
Provides detailed information about which lines of code have been executed
Can be used to identify areas of the code that are not being tested

If you are developing Solidity smart contracts, then I encourage you to use solidity-coverage to improve the quality of your code.

npm install --save-dev solidity-coverage

npx hardhat coverage

When the test code does not cover all smart contracts.

When the test code does cover all smart contracts.

Hardhat : Event filtering (attach, getLogs, topic, Interface, getTransactionReceipt, parseLog)

ReasonJun — Fri, 20 Oct 2023 17:00:03 +0900

import { ethers } from "hardhat";
const contractAddress = "0x5FbDB2315678afecb367f032d93F642f64180aa3";

async function purchase(amount: number) {
  const VendingMachine = await ethers.getContractFactory("VendingMachine");
  const vendingMachine = await VendingMachine.attach(contractAddress);
  const topic = [vendingMachine.filters.Purchase().topics!].toString();
  const filter = {
    address: contractAddress.toString(),
    fromBlock: 0,
    toBlock: 10000000,
    topics: [topic]    
  };
  const logs = await ethers.provider.getLogs(filter);
  //특정 이벤트만 필터링 하기 위한 로그 값
   //console.log("logs >>>", logs)
  let abi = require("../artifacts/contracts/VendigMachine.sol/VendingMachine.json").abi;
  let iface = new ethers.utils.Interface(abi);
  //로그를 분석하기 위해서 abi를 가져옴
  logs.forEach(async(logs) => {
    //실제로 이벤트 로그 내용을 분석하기 위해서는 각각의 트랜잭션 receipt를 가져와서 처리해야 한다.
    const receipt = await ethers.provider.getTransactionReceipt(logs.transactionHash);
    //console.log("receipt >>>", receipt);
    //반복문을 통해서 각로그들의 내용 출력 진행
    receipt.logs.forEach((log) => {
      // console.log("iface.parseLog(log) >>", iface.parseLog(log));
      console.log("purchaser >>",iface.parseLog(log).args[0]);
      console.log("amount >>",iface.parseLog(log).args[1]);
    });
  })
}

// We recommend this pattern to be able to use async/await everywhere
// and properly handle errors.
purchase(10).catch((error) => {
  console.error(error);
  process.exitCode = 1;
});

Here is a breakdown of the script:

import { ethers } from "hardhat"; imports the ethers library.
const contractAddress = "0x5FbDB2315678afecb367f032d93F642f64180aa3"; defines the address of the VendingMachine contract.
async function purchase(amount: number) { defines the purchase() function.
- const VendingMachine = await ethers.getContractFactory("VendingMachine"); creates a contract factory for the VendingMachine contract.
- const vendingMachine = await VendingMachine.attach(contractAddress); attaches the contract factory to the VendingMachine contract at the specified address.
- const topic = [vendingMachine.filters.Purchase().topics!].toString(); defines the topic for the Purchase event.
- const filter = { defines the filter for the getLogs() method.
  - address: contractAddress.toString() specifies the address of the VendingMachine contract.
  - fromBlock: 0 specifies that the logs should be returned from the genesis block.
  - toBlock: 10000000 specifies that the logs should be returned up to block 10000000.
  - topics: [topic] specifies the topic for the Purchase event.
- const logs = await ethers.provider.getLogs(filter); gets the logs for the VendingMachine contract.
- let abi = require("../artifacts/contracts/VendigMachine.sol/VendingMachine.json").abi; imports the ABI for the VendingMachine contract.
- let iface = new ethers.utils.Interface(abi); creates an interface object for the VendingMachine contract.
- logs.forEach(async(logs) => { iterates over the logs.
  - const receipt = await ethers.provider.getTransactionReceipt(logs.transactionHash); gets the transaction receipt for the log.
  - receipt.logs.forEach((log) => { iterates over the logs in the transaction receipt.
    - console.log("purchaser >>",iface.parseLog(log).args[0]); prints the purchaser value of the log.
    - console.log("amount >>",iface.parseLog(log).args[1]); prints the amount value of the log.
  - });
- });
purchase(10).catch((error) => { calls the purchase() function with an argument of 10.
- console.error(error); prints the error to the console.
- process.exitCode = 1; sets the exit code of the process to 1.
}); ends the purchase() function.

This script can be used to analyze the logs of any contract that emits the Purchase event. By parsing the logs, you can get information about who purchased cupcakes, how many cupcakes were purchased, and when the purchase was made.

Hardhat : .to.emit().withArgs();

ReasonJun — Fri, 20 Oct 2023 15:53:40 +0900

import { loadFixture } from '@nomicfoundation/hardhat-network-helpers';
import { expect } from 'chai';
import { ethers } from 'hardhat';

describe('VendingMachine', function () {
  // We define a fixture to reuse the same setup in every test.
  // We use loadFixture to run this setup once, snapshot that state,
  // and reset Hardhat Network to that snapshot in every test.
  async function VendingMachineFixture() {
    // Contracts are deployed using the first signer/account by default
    const [owner, otherAccount] = await ethers.getSigners();

    const VendingMachine = await ethers.getContractFactory('VendingMachine');
    const vendingMachine = await VendingMachine.deploy();

    return { vendingMachine, owner, otherAccount };
  }

  describe('VendingMachine', function () {
  

    it('should send cupcakes correctly after purchase', async function () {
      const { vendingMachine, owner, otherAccount } = await loadFixture(
        VendingMachineFixture
      );
      console.log(
        'vendingMachine cupcakeBalances',
        await vendingMachine.cupcakeBalances(vendingMachine.address)
      );
      const accountTwoStartingBalance = (
        await vendingMachine.cupcakeBalances(otherAccount.address)
      ).toNumber();

      console.log('accountTwoStartingBalance >>', accountTwoStartingBalance);
      const amount = 10;
      await expect(
        vendingMachine
          .connect(otherAccount)
          .purchase(amount, { value: (amount * 10 ** 18).toString() })
      )
        .to.emit(vendingMachine, 'Purchase')
        .withArgs(otherAccount.address, amount);

      const accountTwoEndingBalance = (
        await vendingMachine.cupcakeBalances(otherAccount.address)
      ).toNumber();
      console.log('accountTwoEndingBalance >>', accountTwoEndingBalance);
      console.log(
        'vendingMachine cupcakeBalances',
        await vendingMachine.cupcakeBalances(vendingMachine.address)
      );
      expect(accountTwoEndingBalance).to.equal(
        accountTwoStartingBalance + amount
      );
    });

   
  });
});

.to.emit(vendingMachine, 'Purchase')
    .withArgs(otherAccount.address, amount);

.to.emit(vendingMachine, 'Purchase'): This is a Chai assertion statement. It checks that a specific event, in this case, the 'Purchase' event, is emitted when a certain action is performed on the vendingMachine contract. The .to.emit() syntax is used to make this assertion.
.withArgs(otherAccount.address, amount): This is an additional part of the assertion. It specifies that the 'Purchase' event should have specific arguments when it is emitted. In this case, it checks that the event should have two arguments: otherAccount.address and amount.

In your test case, you are verifying that when the purchase function is called on the vendingMachine contract, it should emit a 'Purchase' event with the expected arguments - the address of otherAccount and the specified amount.

Hardhat : loadFixture(), it(), expect()

ReasonJun — Fri, 20 Oct 2023 15:37:33 +0900

import { loadFixture } from '@nomicfoundation/hardhat-network-helpers';
import { expect } from 'chai';
import { ethers } from 'hardhat';

describe('VendingMachine', function () {
  // We define a fixture to reuse the same setup in every test.
  // We use loadFixture to run this setup once, snapshot that state,
  // and reset Hardhat Network to that snapshot in every test.
  async function VendingMachineFixture() {
    // Contracts are deployed using the first signer/account by default
    const [owner, otherAccount] = await ethers.getSigners();

    const VendingMachine = await ethers.getContractFactory('VendingMachine');
    const vendingMachine = await VendingMachine.deploy();

    return { vendingMachine, owner, otherAccount };
  }

  describe('VendingMachine', function () {
    it('should make 100 cupcake at constructor', async function () {
      const { vendingMachine } = await loadFixture(VendingMachineFixture);
      expect(
        (
          await vendingMachine.cupcakeBalances(vendingMachine.address)
        ).toNumber()
      ).to.equal(100);
    });

  });
});

The loadFixture() function is used to load the state that was setup by the VendingMachineFixture() function.

The it() function is used to define a test. In this case, the test is checking that the VendingMachine contract has a correct balance of 100 cupcakes.

The expect() function is used to make assertions about the state of the test. In this case, the expect() function is asserting that the balance of the VendingMachine contract is equal to 100.