nginx는 주로 정적 파일을 서버에서 반환하기 위한 용도, 서버의 특정 로컬 경로와 외부 접속 경로를 라우팅하는 용도로 사용한다.
nginx를 이용해 특정 경로 별 반환하는 컨텐츠를 구분하거나 도메인 별 컨텐츠 구분 등 기능을 구현할 수 있다.
일반적으로 nginx를 이용한 라우팅은 http, https를 지원하며 각각 지정 포트 80, 443을 기본으로 사용한다.
nginx의 기능이 외부 접속에 대한 최초 컨텐츠 반환이므로, 대부분의 서비스에서 nginx 장애는 서비스 표시 불가 또는 통신 단절 등의 치명적인 문제로 이어진다.
systemd의 재시작 조건을 활성하면 nginx가 오류로 종료되는 등 상황에서 신속하게 프로세스를 다시 실행해 서비스 장애 시간을 최소화 할 수 있다.
# systemd에 등록된 서비스 예시
## 서비스에 대한 설명과 다른 systemd 서비스 또는 커널 상태와 연관된 실행 순서
[Unit]
Description=My Nginx Service
After=network.target ## 사전 실행되어야 하는 서비스 (만약 이 서비스가 도커 컨테이너를 실행한다면, docker 가 사전 실행되어야 함)
## 서비스의 실행 유형과 실행 권한, 실행 명령어, 재시작 조
[Service]
Type=forking ## simple, forking
PIDFile=/run/nginx.pid
User=root
WorkingDirectory=/path/to/nginx
ExecStartPre=/usr/sbin/nginx -t
ExecStart=/usr/sbin/nginx
ExecStop=/usr/sbin/nginx -s quit
ExecReload=/usr/sbin/nginx -s reload
Restart=on-failure ## on-failure, always
## 서버 부팅 시 실행하기 위한 조건
[Install]
WantedBy=multi-user.target ## 일반적 부팅 환경은 multi-user (접속 시 유저 이름과 비밀번호 입력 환경)
nginx config를 변경하거나, nginx 버전 변경 등의 동작을 위해 사용자가 수동으로 nginx를 재시작 하는 경우가 있다.
nginx config 변경은 nginx -s reload 명령어로 수행할 수 있다.
# nginx 명령어를 이용한 관리
nginx -s stop ## nginx 프로세스 즉시 종료
nginx -s quit ## nginx 프로세스를 현재 수행중인 요청 반환 후 종료
nginx -s reload ## nginx config 등 설정파일 다시 적용
nginx -s reopen ## nginx log 파일을 다시 열어 작성
nginx 명령어로 수행할 수 없는 nginx 버전 변경 등 상황에서는 직접 프로세스를 재시작하는 방법을 사용한다.
nginx 서비스가 systemd에 등록되어 있는 경우 한 줄의 명령어로 nginx를 재시작 할 수 있다.
# 자동 재실행 방법
systemctl restart nginx ## 자동으로 서비스 종료 후 시작
# 단계별 실행 방법
systemctl stop nginx ## 서비스 종료 (systemd에 등록한 서비스 명세 중 'ExecStop' 명령이 실행됨, 해당 구문이 없다면 프로세스 kill이 실행됨)
systemctl start nginx ## 서비스 시작 (systemd에 등록한 서비스 명세 중 'ExecStart' 명령이 실행됨)
nginx 서비스를 위의 systemd를 이용해 재실행하는 경우 프로세스가 종료된 뒤 실행되어 요청을 처리할 수 있는 상태가 되기까지 외부 요청에 응답할 수 없는 중단 시간이 발생한다.
서비스의 중단 시간이 치명적인 경우 무중단 프로세스 교체 방식을 사용한다.
이 방식은 nginx 내부에 구현된 커스텀 kill signal을 이용하며, 기존 실행된 프로세스 외에 병렬로 새로운 프로세스 실행 후 상태가 정상인 경우 기존 프로세스를 종료한다.
프로세스가 동시에 2개 존재하는 상태에서는 외부 요청이 분산되어 각 프로세스가 처리하며, 기존 프로세스 종료 시 새로운 프로세스에 모든 요청이 전달되므로 서비스 중단이 발생하지 않는다.
# 기존 실행중인 nginx의 마스터 프로세스 id를 알고 있어야 함
# 기존 실행중인 프로세스와 동일한 config를 가진 새로운 프로세스를 실행하므로 별도 설정 변경이 필요하지 않다.
# 만약 nginx 실행 파일을 변경하는 경우 kill 명령 실행 이전에 새로운 실행파일을 기존 실행파일 위치로 대치해야 한다.
kill -USR2 <old PID> # 새로운 실행파일을 기존 프로세스와 함께 실행 (기존 설정 적용), 기존 프로세스와 새로운 프로세스가 함께 트래픽을 처리
## ps 명령으로 nginx 마스터 프로세스가 기존에 알고 있는 <old PID> 외에 추가로 실행된 것을 확인해야 함
kill -WINCH <old PID> # 기존 프로세스 중단, 새로운 프로세스만 트래픽 처리 (마스터 프로세스는 실행중이지만, 요청을 처리하는 워커 프로세스가 종료되어 요청을 처리할 수 없는 상태가 됨)
## ps 명령으로 <old PID> 를 가리키는 워커 프로세스가 0개가 되고, 새로운 프로세스를 가리키는 워커 프로세스만 실행중인 것을 확인해야 함
kill -QUIT <old PID> # 기존 프로세스 종료, 새로운 프로세스만 남게 됨 (기존 프로세스는 현재 처리중인 요청 반환 후 종료)
## ps 명령으로 새로운 프로세스만 실행중인 것을 확인해야 함
## 실행파일 변경으로 nginx 버전이 바뀐 경우, /proc/<new PID>/exe -v 실행
## 실행 결과로 출력되는 nginx 버전이 의도한 것과 동일한 경우 성공, 이전 버전으로 출력된다면 실행 파일 위치를 다시 확인 후 앞선 작업 재실행
앞선 작업을 실행하는 중 오류가 발생해 작업 이전 상태로 복구하는 경우 아래 명령을 사용한다.
# 기존 프로세스를 대상으로 kill -QUIT 실행 이전에 적용 가능함
# 이미 kill -QUIT을 실행해 기존 프로세스가 종료되었다면, 기존 실행파일을 systemd에 등록된 위치로 대치 후 새로운 프로세스 종료 -> 이전 버전 프로세스 실행 과정을 거쳐야 함
kill -HUP <old PID>
ps -ef |grep nginx # old PID 동작 확인 (master, worker 모두 동작해야 함)
kill -WINCH <new PID>
kill -QUIT <new PID>
일상생활이나 업무를 하며, 우리는 많은 사람들과 소통한다.
소통 과정에서 나에게 당연한 것이 타인에게는 생소한 경험이기도 하고, 반대의 경우도 있다.
나는 이 일상 속에서 서로의 다름을 느끼고, 이해하려 노력한다.
내가 살아온 지난 시간을 되돌릴 수 없지만 다른 사람이 살아온 지난 시간을 대표하는 현재 모습으로부터 간접 경험할 수 있기 때문이다.
가장 표면적인 현재 모습은 소통 방식이다.
개인의 소통 방식은 지난 경험으로부터 얻은 지혜가 녹아 있기도 하고, 지난 불쾌함이 남아 있기도 하다.
만약 첫 소통에서 엄밀한 기준과 범위의 구분을 요구한다면 그 사람은 지난 경험 속 무분별한 범위와 기준으로부터 불쾌함을 겪었거나 기준과 범위 정의로 파격적인 효과를 누렸다고 추측할 수 있다.
나는 이러한 추측을 바탕으로 타인을 이해하려 노력한다.
“왜, 이렇게 소통하지?”
질문으로 시작해서
“이래서 이렇게 소통하는구나”
“이 사람이랑은 “이렇게” 소통하면 좋겠다”
라는 나만의 정의로 마무리하는 짧은 이해 과정이다.
이 과정은 내게 인간관계의 스트레스를 많이 덜어주었다.
이해를 시도해 납득이 가능한 사람이라면, 나의 작은 정의로 정한 소통 방식으로 대화가 가능하다.
이해를 시도했으나 납득이 불가능한 사람이라면, 나는 조금씩 그 사람으로부터 멀어지고 끝내 내 범위 바깥에 둔다.
함께 같은 목표를 가지고 행동한다면 표면적으로 노출되는 작업 방식으로부터 타인을 이해할 수 있다.
나의 작업 방식과 합이 잘 맞을 수도, 잘 맞지 않을 수도 있지만 이해하려는 노력으로 협업 방식을 찾아낼 수 있다.
나는 작업 시 아래 분류를 이용해 우선순위를 지정하고, 차례로 해결한다.
하지만 누군가는 우선순위가 명확하지 않아 상사가 지시한 대로 작업을 수행하기도 한다.
이 경우 나와는 작업 방식이 맞지 않아 협업 시 기대하는 타임라인이 지연된다.
나는 작업 방식이 맞지 않는 타인과 협업 시, 분리하기 규칙을 사용한다.
이 규칙은 작업 분리(역할 구분)와 주체 분리(실행만 위임하기)를 사용한다.
내 작업이 타인에 의해 망가지거나 지연되는 일을 막기 위한 규칙으로, 해결 방법 제시 방식은 내가 예상 가능한 응답을 기대하며 더 효율적인 작업이 가능하다는 장점이 있다.
다만, 규칙을 모든 사람에게 적용한다면 내 작업은 발전하지 못하고 점차 품질이 낮아질 것이기 때문에 신중해야 한다.
나와 같은 사람은 존재하지 않는다.
세상에 내가 말하지 않아도 동시에 같은 생각을 하고, 같은 행동을 하는 사람은 없다.
그렇기 때문에 이해의 과정으로 서로를 알아야 하고, 배려로 상대를 존중해야 원활한 생활이 가능하다.
타인과 소통하며 나와 다른 점이 납득하기 어렵다면, 타인도 나를 납득하기 어려움을 생각해야 한다.
나와 타인이 다른 점을 느끼는 순간은 매우 중요하다.
그 순간 이후에 다름을 이해하려 노력하는 사람과 다름을 배척하는 사람의 미래가 달라지기 때문이다.
모든 사람을 포용해 마찰 없는 이상적인 생활을 할 수는 없다.
하지만 점차 내가 수용 가능한 범위를 넓혀가며 새로운 관점과 경험을 얻지 못한다면, 스스로의 범위를 축소하는 선택이 될 수 있다.
]]>박테리아 내부의 박테리오파지 단백질의 기능 분류를 위해 UniProt50(bacteria taxon) 데이터와 ESM-2 8M 모델 임베딩을 활용해 보았습니다.
지식 그래프 구축을 위해 UniProt 데이터를 노드로 추가하고, 임베딩 데이터를 사전 연산하여 벡터 검색이 가능하도록 준비했습니다.
커스텀 데이터로는 일반적으로 파지 영역을 탐색하고, 단백질 기능을 분석하는 도구인 Phastest 를 활용해 얻어낸 파지 영역 단백질을 이용합니다.
GNN이 단백질 기능 유추에 적합하다고 판단된 이유는, 생물 아미노산 서열에서 번역된 단백질 서열은 조립 순서와 유사한 순서를 가지게 되어 특정 기능 단백질의 주변 영역에서 아미노산 서열 차이보다 안정적인 기준으로 단백질 기능을 사용할 수 있기 때문입니다.
이 경우 동일 종 내의 돌연변이로 인한 아미노산 서열 차이가 생겨도 전체 영역의 기능 변화가 없는 한 주변 단백질과의 관계를 이용해 기능을 유추할 수 있습니다.
ESM-2 를 이용한 단백질 임베딩 벡터를 1차 필터로 사용한 이유는, 아미노산 서열만으로 단백질 관계를 유추하기에 서열 정보의 변동성이 크기 때문입니다.
임베딩 벡터를 사용해 잘 알려진 단백질 정보를 벡터 데이터베이스에 저장 후 분석 대상 단백질의 유사 클러스터를 찾아 GNN의 관계 정보로 사용합니다.
임베딩 벡터를 이용한 클러스터 매칭에 사용된 데이터베이스는 UniProt50 전체를 대상으로 합니다.
주요 타겟 기능은 rbp 이고, rbp 기능은 tail_fiber 하위에 속하는 기능으로 박테리아 표면과 상호작용하는 부위를 의미합니다.
커스텀 데이터 단백질은 서로 앞뒤 관계를 가지고 있습니다. (IS_NEXT_TO, IS_PREVIOUS_TO)
커스텀 데이터의 단백질에 대해 ESM-2 모델의 임베딩을 활용해 UniProt 데이터에서 유사도 상위 50개의 클러스터를 탐색합니다. (유사도 임계값 0.97)
이후 50개의 클러스터 내에서 커스텀 데이터의 시퀀스 길이 대비 0.8 ~ 1.2 배수의 시퀀스를 후보군으로 추려냅니다.
추려진 클러스터를 유사도 기준으로 정렬 후 상위 5개의 클러스터 노드를 커스텀 데이터 노드와 관계짓습니다.(IS_SIMILAR_TO)
학습 후 평가 결과를 보면, unknown 클래스 불균형에도 불구하고 tape_measure, j, portal_protein 등의 서열 변동이 적은 단백질 유추 성능이 기대됩니다.
Unknown 클래스에서 알려진 기능 단백질을 추가 분류하고, 임베딩 사이즈를 키우는 등의 조정으로 더 나은 성능을 기대할 수 있습니다.
커스텀 데이터에서 라벨링 된 기능이 100개 미만인 경우 유추 성능이 매우 낮은 것을 보완하기 위해 대규모 파지 데이터 및 박테리아 데이터를 이용한 사전 학습이 동반된다면 개별 기능 유추 성능 향상을 기대할 수 있습니다.
| precision | recall | f1-score | support | |
|---|---|---|---|---|
| unknown | 0.94 | 0.93 | 0.93 | 8881 |
| rbp | 0.65 | 0.57 | 0.65 | 535 |
| tape_measure | 0.59 | 0.82 | 0.68 | 215 |
| holin | 0.59 | 0.52 | 0.55 | 161 |
| j | 0.66 | 0.90 | 0.76 | 151 |
| tail_sheath | 0.52 | 0.88 | 0.65 | 157 |
| integrase | 0.83 | 0.55 | 0.66 | 137 |
| polymerase | 0.77 | 0.59 | 0.67 | 39 |
| helicase | 0.00 | 0.00 | 0.00 | 51 |
| terminase | 0.55 | 0.83 | 0.66 | 205 |
| portal_protein | 0.86 | 0.72 | 0.79 | 112 |
| capsid | 0.49 | 0.48 | 0.48 | 287 |
| endolysin | 0.26 | 0.06 | 0.10 | 94 |
| primase | 0.00 | 0.00 | 0.00 | 1 |
| tail_fiber | 0.00 | 0.00 | 0.00 | 12 |
| precision | recall | f1-score | support | |
|---|---|---|---|---|
| accuracy | 0.87 | 11038 | ||
| macro avg | 0.51 | 0.52 | 0.50 | 11038 |
| weighted avg | 0.87 | 0.87 | 0.86 | 11038 |
precision : 정답으로 예측한 것 중, 실제 정답인 비율
recall : 실제 정답 중, 정답으로 예측할 비율
f1-score : $2 \times \frac{(precision \times recall)} {(precision + recall)}$
]]>클러스터는 쿠버네티스 환경을 구성하는 네트워크 중 가장 큰 단위를 말한다.
노드라고 부르는 개별 서버들의 합집합이 클러스터(K8s pool)이며, 쿠버네티스 안에서 실행되는 각 Pod의 자원 총량은 클러스터 자원을 넘을 수 없다.
클러스터는 여러 노드를 연결해 하나의 네트워크를 형성하며, 논리적으로 로컬 네트워크와 같이 각 Pod가 소통할 수 있도록 한다.
예) Service(서비스, svc)라는 개념으로 묶인 Pod 간에 통신할 때, 외부 네트워크라면 고유한 IP 또는 도메인을 이용해 호출해야 하는 과정을 K8s 네트워크 안의 고유한 Service 이름으로 호출할 수 있다.
Pod는 K8s 안에서 사용하는 가상 환경 단위이다.
하나의 Pod 당 하나의 가상환경을 가지고, 이미지를 실행한다.
이미지는 docker에서도 사용하는데, 사전 구성된 실행 명령어와 실행 파일을 가진 채 배포할 수 있는 파일을 말한다.
개별 Pod는 고유한 ID를 가지고 클러스터 안에서 실행된다. {svc name}-{Pod ID}
svc는 여러 개의 Pod를 하나의 단위로 묶어 사용할 수 있도록 하는 개념적 집합체다.
svc는 같은 목적으로 실행된 여러 Pod를 논리적으로 포함하며, svc 이름으로 수신된 요청을 하위 Pod들이 자원을 효율적으로 사용할 수 있도록 로드밸런싱 한다.
노드 IP는 각 하드웨어가 가지는 외부 IP를 말한다.
다만 K8s 안에서 각 하드웨어 서버를 노드라고 부르기 때문에 노드 IP라는 이름으로 표현한다.
Cluster IP는 K8s 네트워크 내의 svc가 가지는 고유한 가상 IP를 말한다.
이 IP는 노드 IP와는 다르고, 클러스터 내부 자원에 접속하기 위해서 사용한다.
노드 IP만으로는 별도의 포트포워딩 없이 클러스터 내부 자원에 접속할 수 없다.
클러스터 내부 자원인 svc 호출을 위해서는 클러스터 IP를 이용한 호출이 필요하다.
다만, 클러스터 IP는 외부 IP가 아니기 때문에 로컬 네트워크가 아닌 환경에서 호출할 때 제약이 생긴다.
이 문제를 해결하기 위해서 외부 IP를 가진 노드를 이용해 요청을 수신하고, 클러스터로 전달하는 과정이 필요하다.
아래 설명되는 iptables를 이용해 노드로 수신된 요청을 클러스터로 전달하게 되는데, PREROUTING 과정을 통해 요청의 목적지가 클러스터 내부 Pod IP로 변환된다.
PREROUTING 과정에서 요청의 목적지가 변환되면, iptables의 FORWARD 과정을 거쳐 Pod로 요청이 전달된다.
iptables는 커널 수준에서 사전 정의된 IP로 보내거나 받는 요청을 조율할 수 있다.
iptables는 규칙을 저장해 어떤 IP를 목적지로 하는 요청에 어떤 조율을 할지 정의하며, 실제 요청을 가공하는 작업은 netfilter가 수행한다.
iptables로 지정할 수 있는 규칙은 [ACCEPT, DROP, REJECT, LOG] 등이 있으며, 규칙을 적용하는 대상을 구분하는 종류는 [PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING], 작업을 구분하는 종류는 [filter, nat, mangle, raw] 이 있다.
iptables 규칙과 별개로, INPUT 단계에서 호스트로 전달된 요청의 port를 호스트가 허용하지 않는 경우 요청은 거절된다.
ACCEPT : 패킷 통과 허용, 요청에 대한 응답 정상 반환
DROP : 패킷 폐기, 송신 클라이언트는 폐기 사실을 모른 채 응답을 대기하게 됨
REJECT : 패킷 거부, 송신 클라이언트는 거부 사실을 반환받음
LOG : 패킷 기록, 별도의 작업 없이 해당 패킷을 syslog에 기록함
PREROUTING : 네트워크 도착 즉시 실행됨, 목적지 주소를 바꾸는 용도로 사용
INPUT : 최종 목적지가 현재 서버인 경우 실행됨, 응답을 변환하거나 송신 클라이언트 필터 등에 사용
FORWARD : 목적지가 현재 서버가 아니며 다른 서버로 전달되는 경우 실행됨, 서버를 거치는 요청을 기록하는 용도에 사용
OUTPUT : 현재 서버에서 바깥 네트워크로 송신되는 요청에 실행됨, IP 블랙리스트 호출을 거절하거나 요청 전송 전 정보를 변환하는 용도에 사용
POSTROUTING : 네트워크 작업이 완료된 후 반환되는 시점에 실행됨, 응답 정보 변환하는 용도에 사용
filter : 패킷 허용, 거부, 폐기 등을 결정
nat : IP, 포트 주소 변환
mangle : 패킷 헤더의 정보 변환
raw : 별다른 작업이 없는 순수 요청
iptables로 처리되는 요청은 아래와 같은 순서를 거친다.
외부 -> 내부
- raw(PREROUTING) -> mangle(PREROUTING) -> nat(PREROUTING)
a. mangle(INPUT) -> filter(INPUT) : 현재 서버가 목적지인 경우
b. mangle(FORWARD) -> filter(FORWARD) -> mangle(POSTROUTING) -> nat(POSTROUTING) : 서버를 거쳐 다른 목적지로 전송하는 경우
내부 -> 외부
- raw(OUTPUT) -> mangle(OUTPUT) -> nat(OUTPUT) -> filter(OUTPUT) -> mangle(POSTROUTING) -> nat(POSTROUTING)
산업혁명 시대에는 물품들이 공장에서 제조되기 시작하며 생산 속도와 생산량에 큰 변화가 나타났다.
공장에서 생산되는 물품들은 일정한 공장 가동 주기에 맞춰 작업자가 재료를 투입하거나 완성품을 출하하는 등 기계와 수많은 사람들의 유기적 협력이 필요했다.
이러한 협업 방식이 고정된 시간제 형태로 굳어지며 9시 출근, 6시 퇴근 방식인 ‘9to6’ 가 업무 방식으로 이어져 내려오고 있다.
현대에 들어서며, 공장에서의 직접적인 생산 근로는 기계의 빠른 발전으로 점차 줄어드는 동시에 기계를 관리하는 의사결정 및 업무 조율을 위한 사무 인력이 늘고 있다.
기계와 사람의 동시 협력이 줄어가는 지금, 왜 우리는 아직 이전의 업무 방식인 9to6를 유지하고 있는 걸까?
현대의 디지털 환경을 어릴 때부터 접하며 자라온 젊은 세대와 달리 공장 생산을 경험한 기성세대는 처음 접한 업무 방식이 9to6이며, 오랜 기간 이 방식에 익숙해져 왔다.
이전의 업무 방식에 익숙한 기성세대가 경력이 쌓여 현재 사무 관리직 또는 경영 책임자로서 이전 규칙을 선호하고 유지하려 한다.
이러한 현실적 제약 때문에 우리는 아직 9to6 방식을 주요한 업무 방식으로 이용한다.
9to6가 아닌 10to7, 8to5 등 시차 출근을 채택하는 업무 방식도 존재한다.
다만 이 경우에도 앞뒤 몇 시간을 변동적으로 이용할 뿐, 오후 1시부터 오후 10시까지 근무하는 등 업무 시간의 대폭 변경을 찾기 어렵다.
기존 근무 시간에서 크게 변화를 만들기 어려운 이유는 다른 집단의 근무 시간에 맞춰 소통해야 하기 때문이다.
본인이 오후 1시에 근무를 시작하더라도 거래처는 이미 오전부터 근무를 시작해 각종 안건에 대해 결정을 내리고, 오전 중 회신을 기대한다.
이미 거래처의 결정이 오전에 끝난 상황에서 오후에 출근한 본인은 의사결정 과정에 의견 반영을 기대하기 어렵고, 협업 속도가 느려져 생긴 손해를 감수하게 될 수도 있다.
업무 시간의 변동으로 감수해야 하는 불이익으로 인해 기업의 목적 달성이 늦어지거나 어려워지기 때문에 ‘9to6’ 는 강력한 표준 근로 환경으로 작동하고 있다.
우리는 현대 사회의 유연한 소통 방식과 네트워크를 이용해 자율적인 업무 환경을 기대한다.
하지만 업무를 위해 소통하는 다른 집단과의 원활한 교류를 위해서 업무 환경 타협이 필요하다.
결국 9to6라는 구조는 산업혁명 시대에 고정되어 사회적 타협으로 작동하며 지금까지 이어지고 있다.
]]>과거에는 시간에 맞춰 첨탑의 종을 울려 마을 전체가 공통적인 생활을 할 수 있도록 돕는 직업이 존재했다.
이 직업은 기계의 발전과 동력 기관 비용이 저렴해짐에 따라 더 정확하고 편리한 기계식 알림 방식이 확산되며, 현재는 일부의 이벤트성 문화로 남아 종사하는 사람이 매우 적어졌다.
우리는 앞으로 발전하는 기술로 인해 어떤 변화를 맞이하게 될지 고민해 직업을 선택해야 한다.
직업은 특정 노동에 종사하는 사람들의 유형을 분류하여 “업”이라는 기준으로 표현한 방식을 말한다.
노동의 종류에는 육체 노동과 지식 노동이 존재한다.
우리 사회는 과거 육체 노동이 주요한 문화에서, 정보통신의 발전으로 점차 지식 노동이 주요한 문화로 변화했다.
하지만 최근 인공지능의 발전으로 과거 지식 노동의 많은 부분이 사람에서 기계로 대체되고 있다.
이에 대해 매체에서는 육체 노동으로 직업을 전환하는 사례를 부각하고 있는데, 이는 지식 노동과 인공지능을 이해하지 못함으로 인해 생기는 일부 사례의 과대 해석이다.
인공지능은 과거의 지식 노동 산물을 이용한 도구이다.
인공지능은 과거 기록을 분석해 통계적 패턴을 찾아 같은 유형의 작업을 효율화하고, 기록 간의 연관성을 표현한 정보를 이용해 새로운 정보가 연관된 기록을 확률적으로 찾아내는 작업을 수행한다.
위 내용에 대해 고민해보면, 새로운 유형의 작업과 이전 기록에서 연관성을 충분히 표현하지 못하는 정보에 대해서는 인공지능 작업이 불가하거나 확률이 낮다고 유추할 수 있다.
현재 기술적으로 많은 관심이 있는 생성형 인공지능 또한 위의 기준에서 벗어나지 않는다.
사전 모델 학습 과정에서 과거의 방대한 기록을 서로 연관지어 표현하고, 새로운 정보(질문)에 대해 확률적으로 연관성이 높은 기록을 반환하는 것이 주요 기능이기 때문이다.
이미지나 음성을 만드는 작업 역시 과거의 기록을 연관지어 표현한 상태에서 각 단위(픽셀)을 확률적으로 연관성이 높은 기록으로 반환하여 조합하는 것이다.
반면, 사람의 작업 방식은 인공지능과 다른 점이 존재한다.
사람의 학습 및 일상을 통해 다른 정보를 받아들여 주관적인 표현으로 재구성하는 과정이 유사하지만, 사람은 무모한 도전으로 보이는 새로운 시도로 자신의 주관적 가치로부터 고찰을 통해 새로운 기록을 만들 수 있다.
이전 기록으로부터 연관성이 없는 여러 정보를 조합해 통계적으로 무의미해 보이는 작업에 도전하여 새로운 기록을 만들어낼 수 있다는 점이 인공지능이 대체할 수 없는 사람의 지식 노동 영역이다.
인공지능이 사람보다 효율적인 직업으로 현대 사회에서 선호되는 기업 사무 직업이 있다.
기업 사무에서는 전형적인 Bottom-up 방식으로 정보를 조합하고, 정리하여 보고하는 방식이 작업량의 대부분을 차지한다.
이 작업은 주관적 판단보다는 사실의 전달으로 현상을 효율적으로 판단하는 것이 주요하기에 사람보다 많은 정보를 빠르게 조합하고 표현할 수 있는 인공지능이 효율적이다.
서로 다른 기업의 사무에 대해 조율이 필요한 경우에도, 합리적 결과 도출을 위한 정보 수집 과정은 인공지능이 효율적이다.
사람은 인공지능이 수집한 정보를 이용한 제안 작성, 결과에 대한 의사 집행을 수행하는 작업에 강점을 가진다.
이성적으로는 인공지능이 도출한 결과가 바로 집행되어야 효율적이지만, 기업 간 사무에 앞서 사람 간의 일에서는 관계가 존재하기에 관계의 성격에 따라 제안과 합의 과정이 달라지기 때문이다.
앞선 내용대로 사람이 새로운 기록을 만들어내는 영역에서 직업을 가지는 경우에는 새로운 기록을 효율적으로 표현하고, 기록을 보호하는 도구가 필요해진다.
인간의 영역에서 만들어낸 기록들을 저장하고, 외부와 구분된 영역에서 인공지능이 기록 간의 연관성을 표현하여 또 다른 새로운 기록을 만들기 위한 도구로 활용되는 방식이다.
앞으로의 직업에서는 사람의 고찰 결과를 어떻게 표현하고, 다른 기록과 연관지을 수 있는가에 대한 방법이 중요해진다.
공개된 정보의 열화 및 핵심 정보의 보안으로 인해 범용 인공지능의 한계가 명확해지고, 이후의 작업은 개인의 기록 내부에서 수행되는 인공지능을 활용하게 되는 경우가 내가 생각하는 미래의 모습이다.
가치가 낮은 범용 정보로부터 작은 영감을 얻고, 고찰을 통해 기록을 만들어낸 뒤 개인 기록 안에서의 연관성을 이용한 새로운 영감을 얻는 방식이다.
미래에는 정보 우위가 따라잡을 수 없는 효율성의 차이를 만들어내 사회적 지위, 부의 기준으로 표현될 것이다.
나는 미래 직업에서 필수적인 도구이자 범용 정보의 질을 높이기 위한 플랫폼을 만들고 있다.
STRIGIFIC, 개인이 창출한 기록 소유를 증명하는 동시에 외부와 격리된 환경에서 인공지능을 활용할 수 있도록 한다.
개인의 영감으로 고찰을 이어가 관철한 정보에 대해서는 플랫폼 내의 범용 기록으로 공개하여 내부의 지위를 확보하고, 기록 공유를 통한 새로운 영감의 촉매로 이용되도록 한다.
추후 아래 도메인을 통해 서비스를 제공할 예정이다.
]]>계정 추상화는 프로그래밍 함수를 포괄적으로 사용할 수 있도록 기능을 일반화할 때 사용하는 추상화와 같은 의미로 계정을 변환하는 방식을 말한다.
추상 계정은 특정 목적으로 사전 정의되어 있는 기능 외에 상황에 따라 요구하는 추가 기능을 사용할 수 있는 유연한 기능 범위를 가지게 되어 프로그래밍 가능한 계정으로 변화한다.
예를 들면, 자산의 보관 및 전송을 위한 개인 지갑 계정을 추상화하는 경우 기존에 염두에 두지 않은 NFT 발행 기능을 사용하기 위해 새로운 외부 함수를 호출하는 등의 변화가 가능해진다.
모듈식 계정은 위에서 설명한 새로운 기능 추가를 편리하게 수행할 수 있도록 기능 단위를 모듈화하여 배포한 외부 컨트랙트를 사용하는 방식을 말한다.
모듈식 계정에서 계정 본체는 최소한의 계정 기능만을 가진 OS를 배포하고, 그 외의 계정 기능은 모두 외부 컨트랙트에 배포 후 계정에서 호출 권한을 부여하는 트랜잭션에 서명하여 사용한다.
프로그래밍 시 npm, pip 과 같은 라이브러리 사용을 생각할 수 있다. 라이브러리 설치 도구에 명령어를 입력해 해당 라이브러리를 프로젝트에서 사용하도록 설정하고, 프로젝트에서 라이브러리 기능 사용을 위해 바로 호출할 수 있는 것처럼 모듈식 계정 역시 외부 기능 설치 후 호출 방식을 이용한다.
최근 양자컴퓨터의 상용화 가능성을 두고 많은 주제가 화두에 오르고 있다.
블록체인 서명 체계의 양자 공격 취약성을 경고하며 빠른 대처를 요구하는 의견도 매우 활발하게 논의되고 있는데, 현재 이더리움 네트워크 및 계정 추상화를 지원하는 네트워크는 상대적으로 양자 공격에 대한 대비가 많이 진행되었다고 볼 수 있다.
계정 추상화를 지원하지 않는 네트워크의 경우에는 서명 검증 기능에서 양자 내성 암호를 사용하기 위해 네트워크 전체를 변경하는 하드포크가 필수적이며, 그 과정에서 네트워크 내부 계정들은 새로운 기능 사용을 위해 주소가 다른 새로운 계정으로 자산을 이전하는 등의 방식이 필요하다.
하지만, 계정 추상화를 지원하는 경우에는 네트워크 수준에서 양자 내성 암호 검증 알고리즘 모듈을 추가하는 상대적으로 작은 업데이트와 각 계정의 자율적인 기능 수정으로 양자 내성을 갖출 수 있다는 점에서 양자공격이 일부 대비가 진행중이다.
계정 추상화는 이런 대규모 변화에 대해서도 유연하게 대처 가능한 선택지를 제공하며, 네트워크의 업데이트와 별개로 각 계정의 자율적인 모듈 사용으로 기능을 추가할 수 있다는 점이 특징이다.
계정 추상화 방식에 대해서 네트워크 내부의 추상화 지원, 외부 컨트랙트의 추상화 지원으로 구분할 수 있다.
EIP-4337을 이용한 UserOp, EntryPoint를 이용한 계정 추상화를 플러그인 추상화라고 표현한다.
EIP-4337은 계정 외부 컨트랙트가 계정을 관리할 수 있는 스마트 컨트랙트 기능을 추가하는 제안이다.
이 방식은 외부 컨트랙트가 제출된 UserOp를 EntryPoint라는 신뢰되는 컨트랙트에 전달하여 트랜잭션 실행을 의뢰하는 방식으로 작동한다.
블록체인 네트워크 내부에서는 데이터의 저장, 컨트랙트 간의 소통에 발생하는 비용을 가스비라고 지칭하는데 위의 EntryPoint와의 소통에서 가스비가 발생하여 추상 과정이 없는 단순 트랜잭션에 비해 비용이 높다.
EIP-8141의 프레임 트랜잭션을 이용한 네트워크 빌더 수준에서의 계정 추상화를 네이티브 추상화라고 표현한다.
EIP-8141은 네트워크 빌더 수준에서 Frame 단위 동작을 수행 기능을 추가하는 제안이다.
이 방식은 네트워크 내부 엔진에서 동작을 단위별로 구분하고, 실행하기 때문에 외부 컨트랙트와의 소통 없이 실행되어 트랜잭션 비용이 저렴하다.
Frame을 이용한 추상화로 UserOp로는 여러 개의 요청으로 분리되어야 하는 동작을 하나의 요청으로 수행할 수 있게 되었다.
UserOp는 내부에 동작을 위한 CallData가 하나 포함되어 전달되기에 하나의 UserOp 당 하나의 동작을 수행하여 복잡한 동작을 수행하기 위해서는 여러 개의 UserOp를 이용해야 하는 점에서 높은 비용을 요구한다.
Frame은 내부에 배열 형태로 여러 동작을 순차적으로 요청할 수 있어 순서 관계를 통한 복잡한 동작을 수행하기에 유리하다.
EIP-8141 프레임 트랜잭션은 프레임 모드에 따른 권한 분리가 특징이다.
프레임 모드는 [VERIFY, DEFAULT, SENDER] 가 존재한다.
각 프레임은 트랜잭션 내부에 배열의 요소로 입력되고, 배열 순서에 따라 index 0 부터 순차적으로 실행된다.
블록체인 생태계는 양자컴퓨터라는 새로운 기술에 대응하기 위해 사용자의 자율성을 확대하며, 자연스러운 데이터 이전이 가능한 계정 추상화를 진행하고 있다.
네트워크마다 채택하는 양자 내성 대응 방식이 다양하지만, 이미 네트워크 활성 유저가 많은 대규모 프로젝트에서는 계정 추상화를 이용한 검증 방식 변경이 우세하며 이외의 네트워크에서는 설계 단계부터 양자 내성을 염두에 둔 경우도 존재한다.
양자컴퓨터로 인해 블록체인이 무력화된다는 의견과는 달리 양자컴퓨터 개발 분야에서의 정보 공유를 통해 보안을 강화하는 방향으로 생태계가 발전하고 있으므로 고전적인 네트워크 시스템보다 안전하다.
]]>기록은 현재의 가치를 정리해 미래로 전달하는 방법이다.
우리는 다른 사람에게 정보를 전달하기 위해 기록하는 경우가 많다.
{보고서, 제안서, 편지, 채팅, 논문, 블로그} 등의 형식을 띠는 기록이 다른 사람에게 정보를 전달하는 목적이다.
스스로 생각을 정리하거나 잊지 않기 위해 기록하는 경우도 있다.
{일기, 브레인스토밍, 필기} 등의 형식을 띠는 기록이 스스로를 위해 정보를 정리하는 목적이다.
최근에는 생성형 인공지능의 발달로 위의 두 기록 간 형식 구분이 크게 의미가 없어졌다.
스스로 정보를 정리한 필기를 인공지능을 이용해 보고서 형태로 재구성하는 일이 매우 쉬워졌고, 반대로 복잡한 전문용어를 이용한 논문을 내가 이해하기 쉽게 구어체로 재구성하는 일도 가능하다.
이전 세대에서 역량이 뛰어난 사무 인력은 기록을 보기 편하게 작성하는 사람을 말했다.
퍼져있는 기록을 인용하여 하나의 매체로 정리하고, 기록을 직관적인 시각자료로 표현하는 일은 과거 사무 업무의 큰 부분을 차지했다.
현재는 사무 인력의 보고서 작성 능력이 이전에 비해 덜 중요해졌다.
같은 사람이 작성해도 때에 따라 달라지는 단어 선택과 문맥과 달리, 정규 양식을 사전 학습한 인공지능은 항상 일정한 수준의 결과물을 기대할 수 있기 때문이다.
이 시점에서 우리는 어떤 기록이 중요하며, 어떻게 기록해야 의미를 전달할 수 있는지 고민해야 한다.
인공지능은 과거의 기록을 학습해 얻어낸 기록의 산물이다.
과거의 기록을 찾아내는 능력에 대해서는 사람이 인공지능보다 비효율적이다.
사람은 기록을 찾는 일이 아닌, 새로운 기록을 만들어내는 능력이 인공지능에 비해 효율적이다.
새로운 기록은 이전의 파편 정보를 하나로 엮어내는 일을 뜻하지 않는다.
새로운 기록은 개인이 보유한 고유의 발상을 이용해 기존 기록으로부터 파생한 것을 의미한다.
사람은 인공지능이나 다른 방법을 이용해 정리한 기록으로부터 새로운 사실을 밝혀내기 위해 고민하는 방식으로 기록을 다뤄야 한다.
기존 기록을 바탕으로 새로운 사실을 밝혀내는 활동을 위해서는 유의미한 기록들을 쉽게 모아보고, 골라내는 작업이 중요하다.
유의미한 기록은 아래 기준을 따른다.
기록의 초점이 명확하더라도 의견을 포함하지 않은 것은 유의미한 기록이라기보다는 사실이나 관찰 결과에 가깝다.
우리는 사실과 관찰을 바탕으로 새로운 가능성을 찾아 정리한 유의미한 기록을 해야 한다.
초점이 명확하고 의견을 포함한 기록을 다시 확인하기 위해서 분류를 해야 한다.
분류 방법은 아래 내용에 부합하는 태그를 이용하는 것을 추천한다.
예를 들면 핵심 주제가 “데이터베이스 설계” 라면 바탕이 되는 사실은 데이터베이스의 종류와 특징, 저장 가능한 형태 등일 것이다.
이에 대한 발상 방법은 “고차원 정보 저장을 위한 벡터 분리” 등이 될 수 있다.
위의 두 정보를 조합해 내용을 유추하면, 고차원 벡터 정보를 저장하기 위한 데이터베이스 종류와 효율적인 용량 관리 및 조회를 위한 데이터 분리 방법이 있을 것이다.
우리는 이런 정보를 만들어 기록하고, 미래의 자신 또는 타인이 같은 주제에 대해 더 빠르게 사실을 습득하고 더 깊은 고민을 할 수 있도록 해야 한다.
]]>이더리움 Layer 2 네트워크는 각 목적에 따라 Optimistic, Validity 등의 블록 검증 방식을 이용한다.
이전에 소개한 zkSync Era는 Validity 검증 방식 중 boojum 이라는 증명 알고리즘을 이용하는 예시다.
이 글에서는 Layer 2 네트워크의 블록 증명 방식에 따른 운영 안정성을 고려하기 위한 내용을 다룬다.
Optimistic 검증 방식은 낙관적 블록 생성방식이다.
블록에 오류가 없을 것으로 추정하고, Layer 1으로 블록을 제출하여 약 7일간의 이의제기 기간을 대기한 후 블록을 확정하는 방식이다.
이 방식은 별도의 블록 검증 없이 바로 Layer 1으로 제출하기에 네트워크 처리 연산량이 적다는 장점이 있지만, 블록 오류가 있는 경우 치명적인 네트워크 혼란이 생길 수 있다.
블록 오류가 이의제기 기간 내에 발견되면 Optimistic 네트워크는 오류 블록의 등록을 취소하고, 해당 블록 기록자에 대한 페널티를 부여하는 방식으로 네트워크 신뢰를 확보한다.
오류 블록이 취소됨으로 인해서 해당 블록이 포함하는 트랜잭션 작업이 무효가 되는 것은 아니다.
초기 방식에서는 문제를 발견한 블록에 대해서 큰 비용이 필요하지만 신뢰도를 보장하는 Layer 1에서 다시 블록 내부 작업을 수행 후 정정된 블록을 기록하는 방식으로 오류를 해결했다.
최근에는 문제 블록 내부에서 오류의 원인이 되는 트랜잭션을 찾은 뒤 최소 실행 단위만 Layer 1에서 다시 실행 후 블록을 정정하는 방식도 이용되고 있다.
Optimistic의 이의제기 기간 방식으로 인해 DeFi 서비스 또는 실시간 확정이 필요한 서비스는 불편을 겪을 수 있다.
DeFi 서비스의 경우는 자금 인출이 블록 확정까지 지연되는 점, 실시간 확정이 필요한 서비스는 트랜잭션 실행 결과에 대한 신뢰를 보장할 수 없는 점이다.
악의적인 이의제기로 인해 블록 확정이 무한정 지연되는 문제를 해결하기 위해 검증자 중 올바른 검증을 제출하는 1건의 경우를 이용해서 다른 이의제기를 무효화하는 Optimistic 세부 알고리즘이다.
내부적인 이더리움 가상 머신(EVM)을 이용한 검증 방식이다. 오류 발생 시 Layer 1에서 실행한 EVM을 이용해 블록을 다시 연산하고, 정정한다.
블록의 오류 발생 시에만 영지식 증명(ZK)를 이용해 정정하는 방식이다. Optimistic의 빠른 Layer 1 제출의 강점을 이용하고, 블록 확정 지연시간을 줄이기 위해 ZK로 블록을 검증한다.
Validity 방식은 각 블록에 대해 Layer 2에서 검증 후 Layer 1으로 제출하는 방식이다.
Layer 2 네트워크 내부에서 블록 검증 연산이 실행되기 때문에 네트워크 부담 연산량이 늘어나고, 검증 연산 후 Layer 1으로 블록이 제출되기 때문에 블록의 미확정 시간이 검증 대기열 상태에 따라 변동되는 점이 특징이다.
블록 검증을 위해 영지식 증명(ZK)를 이용해 각 작업 단위를 검증하는 것이 기본 방식이다.
ZK는 연산 방식에 따라 SNARK, STARK로 구분된다.
현재 이더리움 메인넷이 채택한 ZK 는 SNARK 방식이지만, 일부 Layer 2는 메인넷과 별개로 STARK를 채택하여 검증하는 경우도 있다.(대표적인 Layer 2 starknet)
최근 구글의 양자컴퓨터 연구로 확산된 양자내성증명 방식은 STARK 방식이다.
STARK 방식과 SNARK 방식은 기본 알고리즘의 채택이 완전히 달라 서로 다른 특성을 가진다.
SNARK 방식은 각 데이터를 타원곡선 암호를 이용해 암호화하는 방식으로, 양자컴퓨터의 쇼어 알고리즘에 취약한 타원곡선 암호로 인해 양자 위협에 노출된다.
STARK 방식은 각 데이터를 해시 변환을 이용해 암호화하는 방식으로, 양자컴퓨터의 쇼어 알고리즘이 역산하기에 어려운 방식을 이용하여 양자 내성을 가지지만 해시 데이터의 크기로 인해 증명 데이터 용량이 SNARK에 비해 매우 커서 네트워크 연산 부담이 크다.
STARK 방식의 증명을 경량화해 네트워크 부담을 낮추는 방식의 증명 방식이다.
격자기반 암호를 이용하는 증명 방식이다.
STARK 방식의 고성능 증명 방식이다.
별도의 지정 증명 방식 없이 연산 도구만 제공하는 방식이다.
채택 네트워크가 별도로 증명 알고리즘을 지정한다.
이더리움 Layer 2의 사용으로 블록 생성 부담이 줄어 네트워크 가용성이 확보되었지만, 사용자의 체감 가용성은 트랜잭션을 처리하는 RPC 노드의 최대 처리 속도 제한으로 개선이 필수적이다.
높은 처리 속도와 낮은 지연 시간을 요구하는 경우, 트랜잭션 처리 중 노드 오류를 최소화하기 위해 전용 RPC 노드를 사용한다.
RPC 노드는 네트워크를 구성하는 각 노드를 의미하며, 사용자는 임의의 RPC 노드에 트랜잭션을 제출하며 RPC 노드가 로컬에서 트랜잭션 오류 확인 후 다른 노드와 공유하여 저장하는 방식으로 네트워크에 트랜잭션 결과가 저장된다.
전용 RPC 노드는 특정 목적을 위해 RPC 노드를 인증된 사용자만 이용할 수 있도록 제공하는 방식이다.
일반적인 RPC 노드는 다수의 사용자가 제출하는 트랜잭션 처리를 위해 최대 처리 속도가 낮게 설정되는 반면, 전용 RPC 노드는 인증된 소수의 사용자가 제출하는 트랜잭션만 처리하기에 높은 처리 속도를 가진다.
또한, 전용 RPC 노드는 노드 오류로 인한 트랜잭션 지연을 보상하는 구조가 설계되어 있어 기업 서비스에서 트랜잭션 처리 신뢰도를 높이기 위한 수단으로 이용된다.
Layer 2로의 네트워크 확장으로 다양한 RPC 노드가 필요해졌다.
그 이유는 각 네트워크의 블록 생성 방식의 다름으로 네트워크 특화 노드가 필요하고, 블록 증명이 Layer 2 네트워크에서 수행되는 경우 노드의 연산 부하가 블록 생성 속도에 비례해 늘어나기 때문에 연산 능력의 향상이 요구되기 때문이다.
따라서 안정적인 Web3 서비스 운영과 블록 신뢰도를 위해 Validity 방식의 블록 생성 네트워크를 채택하며, 양자내성 네트워크를 고려하는 경우를 고려하면 전용 RPC 노드를 적극 활용해야 한다.
사용 목적에 따른 블록 생성 방식을 제안한다.
| 사용 목적 | 블록 생성 방식 | 특징 |
|---|---|---|
| 실시간 반응형(게임, 소셜 네트워크) | Optimistic | 빠른 Layer 2 기록으로 데이터 송수신 속도 최적화 |
| 데이터 검증형(전자계약, 자산 송금) | Validity | Layer 2에서의 블록 검증을 통한 빠른 블록 확정, 서비스 신뢰를 ZK 증명 방식의 무결성으로 확장 |
서비스에 사용할 네트워크 선정 시 참고할 수 있는 사이트를 아래에 기재한다.
L2Beat
이더리움은 이전 포스트의 내용처럼 지분 증명 방식을 이용한 블록체인 네트워크다.
이더리움은 작업 증명 방식의 네트워크에 비교했을 때 빠른 블록 생성 속도를 강점으로 가지지만, 대용량 트래픽 환경에서는 한정적인 자원으로 인해 사용자 체감 속도가 원활하지 않을 수 있다.
이더리움 네트워크 안에서 블록을 압축해 기록하는 방식으로 특정 계약의 블록 효율을 높이는 시도가 있지만,
이 방식은 네트워크 자체의 속도 향상이 아닌 특정 스마트 컨트랙트 동작을 위한 사전 작업으로
오프체인에서 데이터를 압축하는 과정이 포함되기 때문에 기술적 숙련도를 요구되며, 압축 과정에서의 변조될 위험이 존재한다.
이더리움 네트워크에서 Layer 개념을 이용해 블록 생성 속도 향상, 비용 절감 및 특수 기능을 목적으로 하는 Layer 2 네트워크가 존재한다.
Layer 2에 속하는 네트워크는 자체 네트워크(Layer 2)에서 블록을 생성한 뒤 여러 블록을 모아 이더리움 메인 네트워크(Layer 1)에 블록을 생성하는 방식을 이용한다.
Layer 2 방식을 이용하면 메인 네트워크의 블록 생성 대기열과 별개로 블록을 생성하여 속도 향상을 누릴 수 있고,
Layer 1 의 높은 네트워크 비용을 여러 트랜잭션이 나누어 부담하기에 비용 절감 효과를 누린다.
데이터 무결성과 추적에 대해서는 Layer 2의 트랜잭션 추적과 Layer 1에 기록된 블록 정보를 이용할 수 있으므로 결과적인 보안성은 이더리움 메인 네트워크와 같다.
이 포스트에서는 한국 기술 블로그에 잘 소개되지 않은 ZKsync Era 네트워크의 개념을 소개한다.
ZKsync Era는 Zero-Knowledge proof, ZK(영지식 증명)을 이용하는 이더리움 Layer 2 네트워크다.
영지식 증명은 해시값 비교와 다른 방식으로 데이터를 검증한다.
해시값 비교는 검증자가 원본 데이터를 직접 해시로 변환 후 블록체인에 기록된 데이터 해시와 비교하는 방식을 이용해야 해당 데이터의 변조를 확인할 수 있다.
데이터 검증 과정에서 검증자가 원본을 확인해 민감정보가 유출되거나, 검증자의 조작에 의한 데이터 변조 가능성 문제가 존재하여 영지식 증명 방식이 보안 측면에서 유리하다.