Sweet But Psycho

23.06.30 회고

슈팅스타제제 — Fri, 30 Jun 2023 19:59:13 +0900

왜 원점에 돌아온 것 같은 기분일까

1. 이 티스토리를 과연 기술 블로그라 할 수 있는가

-> 지금까지 작성한 글의 상태 확인

-> 어떤 부분을 개선해야 할지 리스트업

-> 계속 운영하는 것이 맞을지 결정

2. 앞으로 어떤 커리어를 이어갈 것인가

-> 지금까지 진행한 업무 포지션의 비중에 대한 분석 필요 (투자 시간, 실력 도달 범위)

-> 어떤 포지션에 진지하고 꾸준한 관심이 생기는지

-> 해당 포지션의 KPI 분석, 목표 설정

머리가 참 아프다이

23.06.12 Breadth First Search

슈팅스타제제 — Mon, 12 Jun 2023 04:53:54 +0900

Breadth First Search (BFS)

넓이 우선 탐색

그래프 또는 트리 데이터 구조를 순회하거나 검색하는 알고리즘

BFS 의 단계

1. initialization

2. 첫번째 노드를 방문하고 해당 노드의 인접 노드 모두 탐색

3. 모든 노드를 방문할 때까지 해당 작업 반복

BFS 를 구현하기 위해서는 큐 자료 구조를 이용할 수 있다.

BFS vs DFS

왜 BFS 를 구현할 때는 스택을 사용하지 않고 큐를 사용할까?

해당 노드에 대한 인접 노드 정보를 저장할 때 push 하는데

자료 구조의 특성 상, 스택은 가장 마지막에 넣은 노드를 꺼내게 되고 큐는 가장 처음에 넣은 노드를 꺼내게 된다.

이때, 넓이 우선 탐색을 하려면 같은 레벨의 노드를 우선적으로 탐색해야 하므로

다음 레벨의 인접 노드보다 먼저 들어간 노드를 꺼내기 위해서 큐를 사용하는 것이 바람직하다.

코드를 살펴보면

#include <iostream>
#include <queue>
using namespace std;

bool visited[9];
vector<int> graph[9];

queue 에 시작 노드 입력해주고 큐를 비울 때까지 큐의 헤드 요소를 꺼내서 방문 처리를 해준다.

void bfs(int x) {
    queue<int> nodes;
    nodes.push(x);
    visited[x] = true;

    while(!nodes.empty()) {
        int head = nodes.front();
        nodes.pop();
        cout << head << ' ';
        for(int i = 0; i < graph[head].size(); i++) {
            int y = graph[head][i];
            if(!visited[y]) {
                nodes.push(y);
                visited[y] = true;
            }
        }
    }
}

main 함수에서 DFS 와 마찬가지로 인접 노드 설정과 bfs 함수를 실행해준다.

int main() {
    // 노드 1에 연결된 노드 정보 저장 
    graph[1].push_back(2);
    graph[1].push_back(3);
    graph[1].push_back(8);
    
    // 노드 2에 연결된 노드 정보 저장 
    graph[2].push_back(1);
    graph[2].push_back(7);
    
    // 노드 3에 연결된 노드 정보 저장 
    graph[3].push_back(1);
    graph[3].push_back(4);
    graph[3].push_back(5);
    
    // 노드 4에 연결된 노드 정보 저장 
    graph[4].push_back(3);
    graph[4].push_back(5);
    
    // 노드 5에 연결된 노드 정보 저장 
    graph[5].push_back(3);
    graph[5].push_back(4);
    
    // 노드 6에 연결된 노드 정보 저장 
    graph[6].push_back(7);
    
    // 노드 7에 연결된 노드 정보 저장 
    graph[7].push_back(2);
    graph[7].push_back(6);
    graph[7].push_back(8);
    
    // 노드 8에 연결된 노드 정보 저장 
    graph[8].push_back(1);
    graph[8].push_back(7);
    
    bfs(1);
}

실행 결과는 다음과 같다.

## BFS
1 2 3 8 7 4 5 6

## DFS
1 2 7 6 8 3 4 5

DFS 결과와 비교하면 같은 레벨의 노드부터 모두 탐색한 후에

다음 레벨의 노드를 탐색하는 것을 확인할 수 있었다~!~!

23.06.12 Depth First Search

슈팅스타제제 — Mon, 12 Jun 2023 03:49:19 +0900

Depth First Search (DFS)

깊이 우선 탐색

그래프 또는 트리 데이터 구조를 순회하거나 검색하는 알고리즘

그래프에서의 DFS vs 트리에서의 DFS

그래프에서는 노드를 두번 처리해버릴 수 있으므로 방문 여부를 boolean 타입으로 저장하는 배열을 사용하면 좋다!

DFS vs BFS

BFS 와 비교했을 때 DFS 가 어떻게 깊이 우선이 될 수 있는지 생각해보면 (너무 당연하긴 하지만 짚어보자면)

DFS 는 첫번째 노드에서 다음 노드를 탐색하는 기준이 인접 노드를 탐색 후 다음 인접 노드를 탐색하고

BFS 는 인접 노드를 모두 탐색하고 다음 노드로 넘어가기 때문에

DFS 는 깊이 우선, BFS 는 넓이 우선이다.

DFS 의 단계

1. initialization

2. 첫번째 노드를 방문하고 아직 방문하지 않은 인접 노드를 탐색

3. 탐색한 노드 중 하나를 탐색

4. 해당 노드를 방문 처리 후 인접 노드를 탐색

5. 모든 노드를 방문할 때까지 해당 작업 반복

DFS 를 구현하기 위해서는 재귀 또는 스택 자료 구조를 이용할 수 있다.

재귀를 통해 반복하냐 스택으로 탐색할 노드를 관리하냐

방식만 나뉘지 깊이 우선 이라는 점은 바뀌지 않는다.

먼저 재귀를 이용한 코드를 살펴보면

방문 여부를 저장하는 배열과 노드 정보를 벡터로 정의해준다.

#include <iostream>
using namespace std;

bool visited[9];
vector<int> graph[9]; // 아직 인접 노드를 정의하기 전이므로 1차원

먼저 dfs 를 실행하는 함수는 다음과 같이 정의한다.

this is 핵심~!~!

void dfs (int x) {
    visited[x] = true; // 방문 처리
    cout << x << ' ' << endl;
    
    for(int i = 0; i < graph[x].size(); i++){
        int y = graph[x][i]; // 해당 노드 (x) 에 대한 모든 인접 노드 (i) 조사
        if (!visited[y]) dfs(y); // 방문 안했으면 하고
    }
}

다음으로 스택 구조를 이용하면

#include <iostream>
#include <stack>
using namespace std;

vector<int> graph[9];
stack<int> unvisited; // 스택 구조가 추가됨. 
vector<bool> visited(9, false);

가장 위 노드를 스택에서 꺼내오고 방문 처리 및 스택 제거한다.

그리고 현재 탐색 노드에 대한 인접 노드 배열에서 방문 처리가 되지 않았다면 스택 추가한다.

void dfs(int x) {
    int current = x;
    unvisited.push(current);
    visited[current] = true;

    while(!unvisited.empty()) {
        current = unvisited.top();
        cout << current << endl;
        visited[current] = true;
        unvisited.pop();
        for(int i: graph[current]){
            if(!visited[i]) {
                unvisited.push(i);
                visited[i] = true;
            }
        }
    }
}

main 함수에서 인접 노드를 설정하고 노드 1번부터 DFS 단계를 실행한다.

int main() {
    // 노드 1에 연결된 노드 정보 저장 
    graph[1].push_back(2);
    graph[1].push_back(3);
    graph[1].push_back(8);
    
    // 노드 2에 연결된 노드 정보 저장 
    graph[2].push_back(1);
    graph[2].push_back(7);
    
    // 노드 3에 연결된 노드 정보 저장 
    graph[3].push_back(1);
    graph[3].push_back(4);
    graph[3].push_back(5);
    
    // 노드 4에 연결된 노드 정보 저장 
    graph[4].push_back(3);
    graph[4].push_back(5);
    
    // 노드 5에 연결된 노드 정보 저장 
    graph[5].push_back(3);
    graph[5].push_back(4);
    
    // 노드 6에 연결된 노드 정보 저장 
    graph[6].push_back(7);
    
    // 노드 7에 연결된 노드 정보 저장 
    graph[7].push_back(2);
    graph[7].push_back(6);
    graph[7].push_back(8);
    
    // 노드 8에 연결된 노드 정보 저장 
    graph[8].push_back(1);
    graph[8].push_back(7);
    
    dfs(1); // 첫번째 노드 가쥬아
}

TODO: 연결되어 있지 않은 노드를 탐색하는 경우를 처리하는 코드 추가 필요

실행 결과

각 구현 방식으로 실행했을 때, 같은 레벨의 노드에서는 랜덤으로 방문하지만

공통적으로 깊이 우선으로 실행된 것을 확인할 수 있었다~!

## 재귀
1 2 7 6 8 3 4 5

## 스택
1 8 7 6 3 5 4 2

23.05.31 회고

슈팅스타제제 — Wed, 31 May 2023 23:58:29 +0900

연말, 월말이라는 것에 딱히 특별함을 못 느끼는 사람이었지만

이상하게 5월 마지막 날을 지나는 이 순간에 갑자기 스쳐가는 생각이 많아졌다.

뭐 원래도 고민이나 잡생각은 많았지만 저녁 기차를 타고 창밖을 보다 보니

파노라마처럼 오늘, 이번 주, 이번 달, 상반기의 기억들이 지나갔다.

벌써 5월이 끝났다.

5월에 블로그 글 하나는 쓰고 싶었는데 남아있는 임시저장에

끄적거린 글들을 완성시키고 싶은 마음은 아직 안 생기기도 하고

최근에 적은 일기도 짧고 중구난방으로 적어버린 낙서 수준이어서

그냥 떠오르는 생각들을 모아 오랜만에 한 호흡의 유의미한 글로 적어놓고 싶었다.

- 우리는 기대하는 수준까지 올라가는 게 아니라, 훈련한 수준까지 떨어진다

어느 주말 해커톤을 나가게 되었다.

시작 당일에 환경 세팅부터 빌드한 진정한 해커톤이었다.

첫날에는 야심차게 클린 코드로 짜다가 나중에는 마음이 급해져서

컨벤션도 잘 못 지키고 commitment 가 해시값이라 16진수로만 이루어져야 하는데

f 를 넘겨버리는 기본적인 실수도 하게 되었다...하

객관적으로 1인분을 못했다고 생각이 들어서 팀원들에게는 너무 미안하고 나 스스로 속상하기도 했지만

한편으로 다행이라는 생각이 들었다.

계속 모르는 상태로 넘어갔을 수도 있었던 건데 내가 어떤 부분이 부족한지 제대로 느껴서 뭔가 건강검진 받은 기분이었다.

- Hit the Limit

공부하고 있는 내용이 그냥 커피였다면 T.O.P 수준의 프로덕트를 빌드하게 되었다.

아이데이션 단계에서 나오는 대화도 처음 듣는 것이 많았고 이해하기까지 시간도 걸리고 힘들긴 했지만

그만큼 짧은 시간에 많은 정보들을 습득하게 되었고 이제는 용어도 몰라서 벅찬 수준은 벗어나게 되었다.

이번 해커톤의 슬로건이 Hit the Limit 이었는데 제대로 hit 했다. (동시에 hit-hit-"hit" 이기도 했다)

그리고 왜? 라는 물음에 파고드는 힘이 결국 이해력을 결정하는 것을 깨달았다.

해커톤에 같이 나갔던 기획자분이 굉장히 논리적이셨는데 pain point 를 명확히 정리하는 능력이 대단했다.

그리고 프로덕트의 단위를 굉장히 잘게 분해해서 하나 하나 왜? 라는 질문으로 논리를 부여하고

끝에 큰 그림을 완성해내셨는데 나도 그 질문에 같이 흐름을 따라가다가 덕분에 전체적인 프로세스를 이해할 수 있게 되었다.

- 가짜 지식

얼마전 AI 관련 유튜브 영상을 보다가 뇌의 학습 원리와 가짜 지식이라는 것에 대해 생각해보게 되었다.

가짜 지식...그냥 난데..? 너무 찔렸다.

자주 착각을 할 때가 있다.

남에게 깔끔한 설명을 들었다고 내가 아는 것이 되는 게 아닌데...

그리고 술술 이해했다고 하더라도 내 머리로 꼭꼭 씹어먹는 과정이 없으면 (있더라도 다시 복기하지 않는다면)

그냥 휘발된다는 것을 알고 있었지만 머릿속에서 다시 생각하기 귀찮아서 나중에 찾아보자~ 하고 넘긴 적이 굉장히 많다.

그게 쌓여서 큰 구멍이 생기는 것 같다...할 때 제대로 하자. 나는 아무것도 모른다.

23.04.28 [ZK] R1CS

슈팅스타제제 — Sun, 30 Apr 2023 21:44:32 +0900

zkSNARK 에 사용되는 R1CS 에 대해 이해한대로 정리해보았다.

- what is zk-SNARK?

zkSNARK 는 영지식증명 중에서도 비대화형으로 zcash 프로토콜에서 알고리즘으로 개발되어 사용되고 있다.

zk 가 나오게 된 배경, optimistic-rollup vs zk-rollup, zkVM vs zkEVM, zk-SNARK vs zk-STARK 등의 개념은 따로 정리해야겠다.

- what is R1CS?

영지식증명에서는 증명에 사용되는 복잡한 computational statements 를 산술 회로로 모델링하여 계산하는 과정이 필요하다.

따라서, 연산 과정을 최대한 단순화하여 모델링하기에 용이한 시스템으로 이해했다.

뒤에서 설명할 예시는 간단하지만 복잡한 시스템을 R1CS 로 모델링하기 위해서는

보통 circuit 으로 회로를 디자인하고 연산, 증명 및 결과 zkey 를 생성한다.

iden3 에서 제공하는 SNARKjs 라이브러리가 있는데

이걸 사용하면 키 생성 및 연산 결과가 진짜 너무 간단하게 도출되어 생각보다 허무했다.

Rank 1 Constraint System

용어에 대해 살펴보자면, rank 1 행렬은 선형 독립 연산으로

행렬을 소거했을 때 만들어지는 피봇 행렬이 최대 1 인 행렬이며,

constraint 는 회로 연산을 표현한 방정식이다.

R1CS 에서는 3가지 연산 (덧셈, 곱셈, 뺄셈) 만 다루는데,

나눗셈, 모듈러 연산 같은 경우에는 덧셈, 곱셈으로 다시 나타낼 수 있기 때문이다.

- example of R1CS

다음과 같은 임의의 해시 함수가 있다고 할 때,

증명자는 검증자에게 해당 해시 함수를 알고 있다는 사실을 증명하기 위해 4를 대입한 값인 72 를 output 으로 제출할 수 있다.

이때, 검증자는 증명자가 4 라는 값을 사용하여 연산했다는 사실을 모르며,

72 라는 output 과 연산에 사용된 중간값만 가지고도 증명자가 h(x) 에 대한 연산을 했다는 사실을 검증할 수 있다.

계산 과정을 말로 풀어보자면

h(x) 함수의 변수 x 에 대한 차수를 2차로 내리기 위해

먼저 곱셈 연산으로 이루어진 식 x * x 를 변수 sym1 으로 치환한다.

그리고 2차로 내려진 식을 다시 1차로 내리기 위해 x * sym1 을 y 로 치환한다.

그리고 치환한 y - x 를 sym2 로 치환하면 output 에 대한 연산은 치환한 변수를 사용하여

output = sym2 + 7 로 나타낼 수 있다.

위 식을 곱셈 연산 (c=a*b) 의 형태로 나타낼 수 있는데 (1, x, output, sym1, y, sym2 순으로)

먼저, sym1 = x * x 같은 경우에는 a = [0, 1, 0, 0, 0, 0] b = [0, 1, 0, 0, 0, 0] c=[0, 0, 0, 1, 0 , 0]

y = x * sym1 은 a = [0, 1, 0, 0, 0, 0] b = [0, 0, 0, 1, 0 , 0] c = [0, 0, 0, 0, 1, 0]

sym2 = y - x 는 (y-x)*1 로 나타낼 수 있기 때문에 a = [0, -1, 0, 0, 1, 0] b =[1, 0, 0, 0, 0, 0] c = [0, 0, 0, 0, 0, 1]

output = sym2 + 7 도 (sym2 + 7)* 1로 나타낼 수 있기 때문에 a = [7, 0, 0, 0, 0, 1] b = [1, 0, 0, 0, 0, 0] c = [0, 0, 1, 0, 0, 0]

그르면 이제 1차로 내린 행렬 a 들에 대한 행렬 A, b 들에 대한 행렬 B, c 들에 대한 행렬 C 를 만들 수 있다.

그리고 c = a*b 즉, a*b-c = 0 이며 이를 A, B, C 행렬에 대한 스칼라곱 연산으로 변환할 수 있다.

아래 수식에서 S 는 곱셈 연산으로 나타내기 위해 지정한 1, x, output, sym1, y, sym2 에 대한 basis 행렬이다.

행렬 S 의 output 가 7 일 경우, 아래 식을 만족하는 행렬 S 를 계산함으로써 증명이 맞는지 검증할 수 있다.

행렬 C 를 이항하는 이유는 R1CS 는 영벡터를 포함해야 하기 때문인가?

- circuit of zk-SNARK

위 연산을 Circom 의 circuit 으로 회로 게이트 연산을 작성 및 모듈화할 수 있다.

// circuit.circom 

template BadHash() {
	signal private input x;
	signal x_squared;
	siganl x_cubed; 
	signal output out; 

	x_squared <== x * x; 
	x_cubed <== x_squared * xl 
	out <== x_cubed - x * 7;
}

component main = BadHash();

증명자가 계산하는데 사용한 중간 값에 대한 변수는 회로 연산에서 신호 signal 로 나타낼 수 있다. (circom 에서 다루는 변수 타입인 듯)

증명자가 사용한 값 x 인풋값은 검증자에게 알리면 안되므로 private 으로 정의한다.

circom 에서 다루는 연산 기호에 대해 간단히 살펴보자면,

<+ 는 signal 변수에 대한 초기값을 할당하는 역할을 한다.

js 의 = 대입 연산자랑 비슷한 역할을 하나? 생각했었는데

값 할당 외에도 추가적인 constraints 를 설정할 수 있는 역할이 있다고 한다.

그때 이 연산자가 어떻게 작동하는지는 잘 모르겠다. 그리고 초기값으로 설정된 해당 신호의 R1CS 는 a = 3 이 아니라 a - 3 = 0 이다.

a <+ 3;

그리고 <== 연산 같은 경우는 할당은 할당인데 조건부 할당이 가능한 연산자이다.

x_squared <== x * x;

GPT 에 따르면, , a <== (b < c ? 1 : 0)은 b < c라는 조건이 참이면 a에 1을, 거짓이면 a에 0을 할당 한다고 한다.

- 적고보니 드는 의문

1. 행렬 S 에서 output 값으로 인해 x 값이 도출되는 것은 증명자만 알고 있는 사실인가?

이것이 로컬(레이어2)에서 계산되어 레이어 1으로 올라가는건가?

2. SNARK js 에서 증명 연산 결과와 함께 생성되는 증명키, 확인키에는 어떤 값으로 계산되는 것인지 궁금

23.03.12 EIP-1559 가스비 메커니즘

슈팅스타제제 — Mon, 13 Mar 2023 01:18:40 +0900

트랜잭션 날릴 때, 제일 머리가 아픈게 fee 이다.

이더리움의 경우, 단순히 gasPrice * gasLimit 계산해서 넣어주는 것으로 생각하고 있었는데

런던 하드포크 12,965,000 블록부터 EIP-1559 가 반영되었다... 그걸 이제야 공부하다니 반성해야겠다.

EIP-1559 는 왜 도입되었는가?

1. 가스비 변동에 대한 불확실성 감소

estimate 를 통해 평균 가스비를 알 수는 있었지만 시장 원리에 의해 마이너는

더 큰 금액의 가스비를 지불하는 트랜잭션을 우선적으로 블록에 포함시킨다.

이때문에 트랜잭션의 블록 포함 여부는 불확실성이 컸는데 이 문제를 해결하기 위해 기본 fee 개념인 baseFee 를 포함하였다.

2. 블록 사이즈 (단위 블록에 포함되는 가스 수량) 를 통한 트랜잭션 수요 확인

블록 사이즈는 트랜잭션 수요에 대한 지표가 되는데 이전 블록 사이즈와 비교하여 수요가 증가했는지 감소했는지 확인할 수 있다.

블록 사이즈 범위 공식 참조*

어떤 점이 달라졌는가?

기존 트랜잭션은 논스값, gasPrice, gasLimit, 전송 주소, 전송 금액, 트랜잭션 데이터, 서명값을

RLP 인코딩한 데이터로 이루어져있는 구조이다.

그리고 이 트랜잭션 타입은 EIP-1559 에서 LegacyTransaction 타입으로 분류되었다.

rlp([nonce, gasPrice, gasLimit, to, value, data, v, r, s])

바뀐 TransactionType || TransactionPayload 타입은 다음과 같다.

기존 트랜잭션과 달라진 점은 체인 아이디, maxPriorityFeePerGas, maxFeePerGas, destination, (value -> amount) 이다.

(해당 트랜잭션 타입은 트랜잭션 전송의 경우이고 블록에 올라간 트랜잭션 타입은 따로 있고 gasUsed 가 쵸큼 바뀜. )

0x02 || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list, signature_y_parity, signature_r, signature_s])

가스비 측면에서 개념적으로 바뀐 부분은 다음과 같다.

baseFee
maxPriorityFeePerGas: gasPrice - baseFee
maxFeePerGas: baseFee * 2 + maxPriorityFeePerGas

따라서 maxPriorityFeePerGas 또는 maxFeePerGas 중에 하나만 설정해주면 된다.

그로 인한 효과는?

유저는 사실 gasPrice -> {baseFee 와 tip(maxPriorityFeePerGas)} 으로 세분화된 것으로 생각하면 되지만,

마이너(PoS 에서는 밸리데이터) 의 입장에서는 baseFee 는 burn 되고,

남은 maxFee 에서 tip 을 제외한 양은 유저에게 돌아가며 유저가 지불한 tip 만 보상으로 받는다..

기존 트랜잭션에 대한 minorFee

EIP-1559 이후 트랜잭션에 대한 validatorFee

하지만 참고문서에서 가스비가 올라가면서 마이너 fee 가 증가할 수도 있다는 점을 확인할 수 있었다~!

앞으로는 miner fee / validator fee 로 용어를 구분해야겠다~!

메타마스크 고-급 가스 제어 기능

메타마스크에서는 설정에서 해당 기능 토글 온하면

다음과 같이 유저가 tip 값을 설정할 수 있도록 제공하고 있다~!~!

가스비 설정 단계에서 위 [시장] 선택

가스 옵션 [고급] 선택

[우선 요금] tip 값 설정

참고문서링크

https://medium.com/@mrclo0116/eip-1559%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80-29e9da06fff2 [정독할 것]

EIP-1559란 무엇인가

EIP-1559는 고정 수수료와 블록 사이즈의 유동성을 도입한 새로운 트랜잭션 수수료 가격 매커니즘으로, 이더리움의 이코노미 구조에 커다란 영향을 준 업데이트이다.

medium.com

https://www.alchemy.com//blog/eip-1559 [정독할 것 22]

The Developer EIP-1559 Prep Kit

www.alchemy.com

https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md

GitHub - ethereum/EIPs: The Ethereum Improvement Proposal repository

The Ethereum Improvement Proposal repository. Contribute to ethereum/EIPs development by creating an account on GitHub.

github.com

23.03.12 SSZ Simple Serialize

슈팅스타제제 — Sun, 12 Mar 2023 23:08:46 +0900

SSZ 란?

SSZ 는 비콘 체인에서 사용하는 직렬화 방법으로 Merklization 을 하기 위한 데이터 정렬 작업이다.

실행 레이어에서 RLP 직렬화 작업이 이루어졌다면, 합의 레이어에서는 SSZ 로 직렬화 작업이 이루어진다.

그러면 직렬화란 무엇인가?

데이터 구조를 저장 또는 다른 노드와 데이터 통신할 경우, 파싱할 수 있는 형태로 만들기 위해서 변환하는 작업을 말한다.

예를 들어 참조형 데이터를 통신하는 경우, 메모리 주소에 있는 값을 참조하게 되는데

이때, 데이터를 받은 노드의 메모리 주소에는 다른 값이 존재할 수 있기 때문에

참조형 데이터의 주소값에 대한 데이터를 값 타입 데이터로 변환하는 작업을 거쳐야 한다.

이더리움에서의 직렬화는 unsigned int 와 boolean 의 기본 타입 변수로 변환하는 것이다.

SSZ 의 offset 과 바이트 스트림 형태

위 타입의 변수는 고정 길이로 little-endian 바이트로 변환하는 작업만 하면 되지만

Struct 타입과 같은 가변 길이의 데이터는 offset 이 적용된 값으로 처리된다.

아래는 Struct -> unsigned int 로 offset 을 적용한 직렬화 예시이다.

struct Dummy {
    number1: u64, 
    number2: u64, 
    vector: Vec<u8>, 
    number3: u64
}

dummy = Dummy {
    number1: 37, 
    number2: 55, 
    vector: vec![1, 2, 3, 4], 
    number3: 22,
}

serialized = ssz.serialized(dummy)

serialized 에 담기는 값은 다음과 같다.

[37, 0, 0, 0, 55, 0, 0, 0, 16, 0, 0, 0, 22, 0, 0, 0, 1, 2, 3, 4]

이때, 벡터 위치에는 offset 값이 들어가고 벡터 값은 number 3 의 값 뒤에 위치한다.

여기서, 16의 의미는 벡터에 대한 값이 어느 위치에서 시작하는지 나타내는 값이다!!

(벡터값 1, 2, 3, 4 가 인덱스 16 에서 시작하므로 해당 값을 넣어준 것이며,

가변 길이 타입의 실제 값은 직렬화 데이터 끝에 있는 힙에 저장된다.)

그리고 number 1 변수를 little-endian 바이트로 인코딩한 것은 실제로 32비트의 값을 가지지만,

예시에서는 u64 변수와 벡터 변수의 위치 관계를 명시하기 위해서[37, 0, 0, 0, ...] 의 4비트 자리로 표현하였다!

실제 인코딩된 바이트 스트림 형태는 다음과 같다.

[
  10100101000000000000000000000000  # little-endian encoding of `number1`
  10110111000000000000000000000000  # little-endian encoding of `number2`.
  10010000000000000000000000000000  # The "offset" that indicates where the value of `vector` starts (little-endian 16).
  10010110000000000000000000000000  # little-endian encoding of `number3`.
  10000001100000101000001110000100   # The actual value of the `bytes` field.
]

Merklization

SSZ 직렬화 과정을 거치면 머클 루트 계산 가능하다!

위에서 계산한 SSZ 값에 대한 머클 루트를 계산하는데

이때, 각 leaf 에 대한 일반화 지수에 대한 계산 식은 다음과 같다. (결국에는 노드 인덱스)

2 ** 요소의 depth + 해당 열에서 요소의 index

MultiProof

Merklization 는 proof (아마 트랜잭션 결과에 대한 proof 말하는 듯?) 루트값에 대한 검증이 가능하다.

예를 들어 아래와 같은 트리 형태인 경우,

9번 값을 검증하기 위해 먼저, 해시(8, 9) 와 해시(4) 가 같은지 확인해야 하고

해당 값에 5를 해시하고(=> 해시 2) 또, 해당 값에 3을 해시하여 (=> 해시 루트 1)

1번 인덱스의 해시 루트 값을 생성하는 식이다.

따라서, 이 과정에서 데이터가 잘못되었을 경우, 루트값이 바뀌므로 다중 증명 검증이 가능하다.

위 직렬화는 노드의 트랜잭션 처리를 위한 개념이지만, 데이터가 어떻게 직렬화된 것인지 알아보는 것은

곧 인코딩이 어떻게 처리되었는지 이해하는 것이기 때문에 필요한 개념이라고 생각한다.

각 네트워크의 주소 유효성 검사, 니모닉 유효성 검사를 무지성 처리하기 전에

어떤 인코딩 방식으로 데이터가 처리되었는지 확인해봐야겠다~!~!

참고문서링크

https://ethereum.org/en/developers/docs/data-structures-and-encoding/ssz/

Home | ethereum.org

Ethereum is a global, decentralized platform for money and new kinds of applications. On Ethereum, you can write code that controls money, and build applications accessible anywhere in the world.

ethereum.org

23.03.09 [ResourceNotFound]not found nft

슈팅스타제제 — Thu, 9 Mar 2023 16:24:03 +0900

caver 로 NFT 컨트랙트 주소를 통해 데이터를 받아오는 중에 다음과 같은 에러 메세지가 나왔다.

{"_code": 1040400, "_message": "[ResourceNotFound]not found nft", "_requestId": "8f011c9a-f0de-936d-9206-db855f38aa22"}

원인은 크게 세가지로 보고

1. 클레이튼 메인넷 호출 여부 (chainId)

2. contract address

3. EOA address 인자값을 체크했는데 다 이상없었다.

그리고 이상한 것은 같은 클레이튼 네트워크의 다른 컨트랙트 NFT 는 다 잘 나오는데 얘만 안나온다했더니

해당 컨트랙트의 Account Key 값이 AccountKeyFail 상태였다.

키값의 상태는 총 5개로

1. AccountKeyLegacy

2. AccountKeyPublic

3. AccountKeyFail

4. AccountKeyWeightedMultisig

5. AccountKeyRoleBased

AccountKeyFail 상태는 트랜잭션 유효성 검증 프로세스는 항상 실패한다는 공식문서 내용을 확인할 수 있다.

caver 의 contract method 로 컨트랙트 호출할 때, 조회도 불가능

여기서 이상한 것은 세 가지다.

- AccountKeyFail 상태일 때, 트랜잭션 유효성 검증이 실패한다는 것은

컨트랙트 호출을 통한 거래도 할 수 없는 상태라는 것인데

opensea 에서는 2 days ago 로 이틀 전에 transferFrom method 가 호출되었다. 뭔데..

- 그리고 이 NFT 는 opensea 에서 hidden 으로 분류되었고

- opensea 에서는 어떻게 이 NFT의 메타데이터를 모두 가져올 수 있는지 의문

23.02.16 치즈 만들기

슈팅스타제제 — Thu, 16 Feb 2023 23:07:57 +0900

1. 기본 사각형에서 edit mode 로 간다.

2. 점 두개 shift 선택하고 우클릭 ⇒ Vertex Context Menu ⇒ Merge Vertices ⇒ At Center

삼각형 치즈를 만들기 위해서는 아랫면의 점들도 해준다.

여기까지는 괜찮은데 그 뒤에 softly 하게 만드는게…쵸큼 빡세다.

일단 ctrl + B 로 면을 잘게 갈아준다.

처음에 딱 한번만 누르면 한번만 간 효과가 나오는데

여기서 마우스 없이 wheel 돌린 효과 내는 법을 내기 위해서 shift 하고 위로 슥슥 밀어준다.

Object Mode 간 다음에 Add Modifier ⇒ Subdivision Surface

Object ⇒ Shade Smooth

shift + A ⇒ 객체 생성 (UV Spear)

Edit Mode

shift + D ⇒ 객체 복붙

다하고 Object Mode 와서

Viewport 1 → 2 변경

Add modifier ⇒ Boolean ⇒ 스포이드 아이콘 눌러서 Sphere 터치!

근데 킹받게 이렇게 되고

Add Modifier ⇒ Edge Split

다시 sphere 추가하고 두둥

apply 다 눌러준다.

light Area 추가하고

조명 살짝 주고 렌더링하면 맛있는 치즈 완성~!~!

23.02.05 왜 super call?

슈팅스타제제 — Sun, 5 Feb 2023 23:31:06 +0900

Constructors for derived classes must contain a super call

super() 을 호출하지 않으면 위와 같은 타입스크립트 에러로 this 로 서브 클래스에 접근할 수 없다. (타스만의 에러는 아님.)

해주면 그럼 뭐 에러는 해결인데 왜 해줘야 하는지 좀 의문..

서브 클래스에서 constructor 가 실행될 때, 생성자 함수에서는 슈퍼클래스에 빈 객체를 만들고 this 로 객체 할당해주라고 기다리고 있다.

그러니 서브 클래스 입장에서는 그냥 못 만들고 super() 을 호출해서 슈퍼 클래스의 constructor 를 실행해야 하는 것이다.

그러면 비로소 this 객체가 만들어지고 this. 를 사용할 수 있다~!~!