개발하기좋은날

GIT 다 계정 SSH 설정 방법

devbi — Sat, 1 Apr 2023 15:54:40 +0900

준비물

작업 환경 : Mac (window에서도 비슷한 과정으로 했는데 잘 됐어요 )
터미널
등록 계정 예시 (이메일이거나 아닌 경우 각자 상황에 맞춰서!)
- 개인 계정 : gaegul
- 오피셜 계정 : gaegul@gaegulcompany.com

ssh-key 생성

$ cd ~/.ssh // 루트경로에서 ssh 숨김 폴더로 이동 
$ ssh-keygen -t rsa -b 4096 -C 'gaegul'

터미널을 열어 ssh 숨김 폴더로 이동 후 깃헙 계정을 등록해 줍니다.

-t ras : 암호화 방식을 rsa로 지정
-b 4096 키의 바이트 크기를 최대로 지정해 줍니다.
-C ‘gaegul’ 계정을 추가해 주세요. 메일이라면 메일 형태로 추가해 주시면 됩니다.

$ file in which to save the key (/Mac/.ssh/id_rsa): id_rsa_stduy

잘 작성했다면 위와 같은 설정에 관한 내용이 나옵니다.
저는 개인 계정이므로 키값을 id_rsa_study로 해 주었습니다.
계정 2개 구분을 위한 값이니 본인이 구분하기 편하도록 작성해 주세요.
작성하지 않고 엔터치면 기본값 id_rsa로 설정됩니다.

$ Enter passphrase (empty for no passphrase):
$ Enter same passphrase again:

다음에 비밀번호 입력 메세지가 나오는데, 저는 비밀번호 설정없이 엔터쳐서 넘겼습니다.

자, 이제 첫번째 개인 계정 ssh key 파일이 생성되었습니다.
위 과정을 반복하여 오피셜 계정도 등록해 주세요.

$ ssh-keygen -t rsa -b 4096 -C 'gaegul@gaegulcompany.com'
$ file in which to save the key (/Mac/.ssh/id_rsa): id_rsa_work

오피셜 계정이며, 키값은 id_rsa_work입니다.
이후 엔터, 엔터해서 비밀번호 설정까지 완료해 주세요.

$ ls

ls 명령어로 생성된 파일 목록을 확인해 봅니다.

pub가 붙지 않은 것은 비공개 ssh이며 *.pub 파일은 공개 ssh를 의미합니다.

id_rsa_study
id_rsa_study.pub
id_rsa_work
id_rsa_work.pub

내용이 많아 보이지만 간단합니다 :)

ssh-key 등록

$ eval "$(ssh-agent -s)"

더 슬기롭고 편리한 깃헙 생활을 위하여 생성한 키를 ssh-agent에 등록합니다.

$ ssh-add ~/.ssh/id_rsa_study
$ ssh-add ~/.ssh/id_rsa_work

환경설정

계정 별로 SSH 설정파일을 작성합니다.
해당 경로에서 직접 파일을 생성해도 되고, vim을 켜서 작업해도 무방합니다.

Vim으로 환경설정 작성

폴더 생성 후 vim 에디터 열기

$ touch ~/.ssh/config //.ssh폴더에 config 폴더를 생성
$ vi ~/.ssh/config //vim 에디터 열기

vim 에디터가 열렸으면 아래와 같이 개인에 맞춰 작성합니다.

#  깃헙계정 work
#  -------------------
Host github.com-work
  HostName github.com
  IdentityFile ~/.ssh/id_rsa_work
  User gaegul@gaegulcompany.com 

# 깃헙계정 study
#  -------------------
Host github.com-study
  HostName github.com
  IdentityFile ~/.ssh/id_rsa_study
  User gaegul

작성 완료했다면 vim 명령어로 저장하고 나오기
ESC 누르고 :w 로 저장을 합니다. 마지막으로 :q 입력하여 에디터 종료

Github SSH 설정

github에 로그인하여 설정 페이지로 이동합니다.

우측 프로필 사진 드롭다운 클릭
Settings
좌측 사이드바 SSH and GPG keys
New SSH Key

title : 아무거나. 저는 키 타이틀이랑 똑같이 했어요.
key : 각 key의 _pub 값을 복붙해서 넣어주면 됩니다.

key값 복사하는 방법

1. 파일 열어서 직접 복사

$ open .

.ssh 폴더에서 저는 open . 명령어로 파인더를 열었고, pub 파일 두개 vscode로 열어서 키값 복사하기

2. 명령어로 복사

$ pbcopy<~/.ssh/id_rsa_study.pub
$ pbcopy<~/.ssh/id_rsa_study.work

이 단계에서 중요한 점은 각 계정별로 깃허브에 로그인하여 키값을 각 계정별로 등록해야 합니다.

잘 되었나…!

잘 등록이 되었을까요? 테스트 해봅시다.

$ ssh -T git@github.com-work
$ ssh -T git@gitbhu.com-study

잘 연결이 되었다면 아래같은 멘트가 나옵니다! 유후
Hi gaegul! You’ve successfully authenticated, but GitHub does not provide shell access.

계정 별 remote 설정하기, clone받기

이렇게 설정하고 저도 몇 번 까먹어서, 왜 안돼;; 했던 부분인데요.
보통 저는 레포지토리 클론받을 때, https url 카피하고,

git clone https://github.com/gaegul/gageul-repo

위의 명령어로 받았습니다.
하지만 이제 우리의 ssh key를 생각해 주세요!

git clone git@github.com-study:gaegeul/gaegul-repo.git
git clone git@github.com-work:gaegeul@gaegulcompany.com/gaegul-repo.git

github.com-키네임 을 입력해 주시면 됩니다.
remote도 동일하게 진행합니다.

git remote add origin git@github.com-study:gaegul/gaegul-repo.git

이후 각각 git config --local user.name, email 설정해서 사용하면 됩니다

- 출처

https://minimal-dev.tistory.com/36

Mac에서 Github 여러 계정 사용하기

github 개인 계정 하나만 사용하다가, 사이드 프로젝트를 시작하며 프로젝트용 계정도 사용하게 되었는데. 새로운 계정으로 커밋하는 과정에서 에러 발생. 에러.에러.에러.무한에러의 늪에 빠졌

minimal-dev.tistory.com

10년 전과 달리 금융은 블록체인 기술이 확산한 세상에서 미래를 제시한다

devbi — Mon, 6 Feb 2023 08:48:10 +0900

블록체인 기술이 금융에 미치는 영향
암호화폐의 미래: 어떤 방향으로 변화할까?
STO(Security Token Offering)의 대세: 금융 투자의 새로운 길
디지털 금융의 미래: 금융 기업들이 어떤 변화를 추진하고 있나?
금융 공공 정책: 디지털 금융을 위한 정책 방향
금융 산업에서의 블록체인 채용: 어떤 직무에 블록체인 기술이 적용되고 있나?
디지털 자산 관리: 안정적인 투자를 위한 기술
디지털 암호화폐의 법적 규제: 국가의 대책은 어떤것인가?
디지털 암호화폐 거래소의 보안: 투자자의 안정성을 위한 노력
금융의 미래: 블록체인 및 디지털 자산이 어떻게 환경을 변화시키고 있는지

블록체인과 디지털 자산이 금융계의 새로운 표준으로 빠르게 자리 잡고 있다.

비트코인, 이더리움 등 암호화폐의 부상부터 보안토큰오퍼링(STO), 탈중앙화금융(DeFi) 등의 성장까지 금융산업은 큰 변화를 겪고 있다.

이번 게시물에서는 이러한 혁신적인 기술들이 전통적인 금융 시스템을 어떻게 변화시키고 있는지, 투자자와 소비자 모두에게 어떤 의미가 있는지 자세히 살펴볼 것이다.

먼저 기존 금융과 블록체인 및 디지털 자산이라는 신세계의 주요 차이점을 살펴보자.

소수의 대형 금융기관에 의해 중앙 집중화되고 통제되는 전통적인 금융과 달리 블록체인과 디지털 자산은 복잡한 알고리즘과 암호화된 데이터에 의해 분산되고 구동된다. 이를 통해 인터넷에 연결된 모든 사용자가 액세스할 수 있는 보다 안전하고 투명하며 효율적인 시스템을 사용할 수 있습니다.

다음은 이러한 새로운 기술이 어떻게 투자 방식을 변화시키고 있는지 살펴보겠습니다. DeFi의 성장과 함께, 투자자들은 이제 P2P 대출과 분산된 거래소와 같은 더 넓은 범위의 투자 기회에 접근할 수 있다. 이러한 플랫폼은 수익을 창출하고 자본에 액세스할 수 있는 새로운 방법을 제공하는 동시에 투자를 더욱 효과적으로 제어할 수 있습니다.

마지막으로, 우리는 금융 세계에서 블록체인과 디지털 자산의 잠재적인 미래에 대해 논의할 것이다. 언젠가 전통적인 법정화폐를 대체할 수 있는 디지털 화폐의 개발부터, 아직 상상할 수 없는 새로운 금융 상품과 서비스의 성장까지, 가능성은 무궁무진하다.

전반적으로, 이 게시물은 빠르게 진화하는 블록체인과 디지털 자산의 세계와 그것들이 금융 산업에 미치는 영향에 대한 포괄적인 개요를 제공할 것이다. 투자자든 소비자든 금융의 미래가 궁금할 뿐이든 이 게시물은 필독서다.

그러니 저와 함께 금융의 흥미로운 미래를 탐색해 보시조!

블록체인 STO, 대한민국 금융의 미래

devbi — Fri, 3 Feb 2023 06:39:26 +0900

한국은 항상 기술과 금융의 선두주자였고, 블록체인 기술을 금융산업에 접목하는 것이 그 다음 단계다.

보안 토큰 오퍼링(STO)은 기업이 자본을 조달할 수 있는 방식과 투자자가 새로운 기회에 액세스할 수 있는 방식에 혁명을 일으키고 있습니다. 이 블로그 게시물에서 우리는 STO의 흥미진진한 세계와 그들이 한국에서 금융의 얼굴을 어떻게 바꾸고 있는지 탐구할 것이다.

STO는 기업이 기업 내 소유권을 나타내는 디지털 토큰을 발행하는 새로운 형태의 투자다. 이 토큰들은 모든 거래의 분산 원장인 블록체인에 저장된다. 이는 투자자들이 은행이나 브로커와 같은 중개인 없이도 쉽고 안전하게 STO를 사고 팔 수 있다는 것을 의미한다.

STO의 가장 큰 장점 중 하나는 전통적인 기업공개(IPO)에 비해 일반인들이 훨씬 쉽게 접근할 수 있다는 점이다. IPO는 역사적으로 기관투자자와 순자산이 높은 개인에 한정돼 있었지만 STO는 인터넷 연결이 가능한 누구나 참여할 수 있도록 했다. 이것은 일상적인 사람들에게 완전히 새로운 투자 기회의 세계를 열어준다.

기존 투자 방식에 비해 훨씬 투명하다는 점도 STO의 장점이다. 모든 거래가 공개된 블록체인에 기록돼 누구나 STO를 누가 어떤 가격에 사고팔았는지 알 수 있다. 이러한 수준의 투명성은 전통적인 투자 방법에서 공통적으로 우려되는 사기 및 잘못된 관리의 위험을 줄이는 데 도움이 될 수 있습니다.

한국 정부는 STO의 잠재력을 인식하고 이들의 성장을 뒷받침할 규제 틀을 만들기 위한 조치를 취하고 있다. 금융위원회(FSC)는 2019년 한국블록체인협회를 만들어 국내 블록체인 기술 개발을 총괄하고 있다. 금감위는 또 금융투자협회와 함께 STO의 안전성과 투명성을 보장하기 위한 가이드라인을 만들고 있다.

결론적으로, STO는 한국 금융 산업의 판도를 바꾸는 요소이다.

그들은 전통적인 투자 방법보다 접근하기 쉽고 투명하며 모든 사람을 위한 금융을 민주화할 수 있는 잠재력을 가지고 있다. 블록체인 기술이 계속 발전함에 따라, 우리는 STO의 세계에서 훨씬 더 흥미로운 발전을 기대할 수 있다. 그러니 금융의 미래에 참여할 준비를 하고 오늘부터 STO에 투자를 시작하세요!

한국 금융의 미래: 암호화폐가 가져올 기회와 위험

devbi — Wed, 1 Feb 2023 07:48:12 +0900

한국의 금융 시장은 빠르게 변화하고 있습니다.

최근에는 암호화폐의 인기가 높아지면서 금융 업계에서도 많은 논의가 이루어지고 있습니다.

암호화폐의 등장은 금융 시장에 기회를 가져오지만, 동시에 새로운 위험도 가지고 있습니다.

암호화폐는 블록체인 기술의 발전에 따라 많은 이용자들이 투자하는 새로운 자산이 되었습니다.

암호화폐를 이용한 거래는 금융 시스템의 제약을 극복하여 신속하고 효율적으로 거래할 수 있는 장점이 있습니다.

하지만, 암호화폐의 가치는 불안정하며 가격 변동이 큽니다.

또한, 많은 암호화폐 거래 플랫폼이 존재하지만 보안에 대한 문제가 존재합니다.

이러한 금융에서는 지적 자산이 발전하고 있습니다.

지적 자산은 블록체인 기술을 기반으로 하는 암호화폐의 확산과 투자자들의 관심으로 인해 많은 주목을 받고 있습니다.

한국의 금융 시장은 금융 기술의 발전에 따라 많은 변화를 겪고 있습니다.

예를 들어, 전자 금융, 모바일 금융, 클라우드 금융 등이 주목을 받고 있습니다. 이러한 변화는 고객의 경험을 향상시키고, 금융 서비스의 편의성을 높여주고 있습니다.

또한, 한국의 금융 기업들은 금융 기술의 발전에 따라 더욱 경쟁력 있는 금융 서비스를 제공할 수 있는 기회를 가지게 되고 있습니다. 이는 금융 시장의 활성화와 경쟁력의 강화로 이어질 것입니다.

암호화폐의 인기는 금융 시장에서 한국의 금융 시장은 크고 발전한 정책 및 기술의 지원을 받아 글로벌 경쟁력이 높은 국가입니다. 금융 기관은 다양한 금융 제품과 서비스를 제공하여 고객의 금융 요구에 맞춰 지원하고 있습니다.

한국의 금융 시장에서는 은행, 증권, 보험, 암호화폐 등 다양한 금융 제품을 제공하고 있습니다.

은행은 금융 제품의 기본이 되며, 저축, 대출, 금융 상품 등을 제공합니다. 증권사는 주식, 펀드, 보험 등의 증권 제품을 제공하여 고객의 투자 요구에 대응합니다. 보험 기관은 생활 사고, 질병, 재산 등에 대한 보장 제품을 제공합니다.

그 외에도 암호화폐는 금융 시장에서의 새로운 혁신적인 제품으로 큰 관심을 받고 있습니다.

암호화폐는 블록체인 기술을 기반으로하며 미래에 대한 긍정적인 기대감을 가지고 있습니다.

금융 기업들은 금융 기술의 발전에 따라 새로운 서비스와 기술을 개발하고 있습니다. 이러한 개발은 금융 서비스의 편의성과 안정성을 향상시켜줍니다.

그러나, 암호화폐와 같은 새로운 금융 기술이 등장하면서 감사와 보안 문제가 발생할 수 있습니다. 금융 기업들은 이러한 문제를 해결하기 위해 노력하고 있습니다.

앞으로 한국의 금융 시장은 계속해서 발전할 것으로 기대됩니다.

한국 경제, 새로운 시대의 파생: 기술 미래지향 전략의 중요성

devbi — Tue, 31 Jan 2023 11:42:04 +0900

한국 경제는 새로운 시대에 대한 준비를 하고 있다.

기술 미래지향 전략이 한국 경제의 미래를 정의하는 중요한 역할을 하고 있다. 특히, 기술의 발전에 따른 경제 변화와 글로벌 경쟁 환경 변화를 앞세우는 경우에서 기술 미래지향 전략은 더욱 중요한 역할을 할 것이다.

기술의 발전은 경제 변화를 일으키며, 경제 생태계의 구조와 산업 패턴이 바뀌게 한다. 특히, 인터넷과 기술이 점점 더 중요한 역할을 하고 있어서, 기술 미래지향 전략이 중요해지고 있다. 한국 경제는 이러한 변화에 대해 긍정적으로 대처하고, 기술을 활용하여 경제 발전을 추진하고 있다.

기술 미래지향 전략을 적극 적용함으로써 한국 경제는 새로운 산업을 창출하고, 기존의 산업을 혁신할 수 있다.

기술을 활용하여 경제의 효율성을 향상시키고, 새로운 비즈니스 모델을 개발할 수 있다.

또한, 기술의 발전은 새로운 직업과 일자리를 창출할 수 있다.

한국 경제의 미래를 위해 기술 미래지향 전략이 각 산업에서 적용되어야 한다.

기술을 활용하여 경제의 발전을 추진하는 것이 경제의 미래를 보장하는 데 필요한 것이다.

기술 미래지향 전략은 경제의 미래를 관찰하고, 경제의 변화에 대한 대처 전략을 개발할 수 있다.

또한, 기술 미래지향 전략을 적용하면 경제 규모를 키울 수 있다.

기술을 활용하여 새로운 비즈니스 모델을 개발하면, 새로운 시장을 창출할 수 있고, 기업 수익성을 향상시킬 수 있다. 또한, 기술의 발전은 경제의 효율성을 높일 수 있어, 경제가 더욱 안정적으로 발전할 수 있다.

한국 경제의 미래를 위해서는 기술 미래지향 전략을 적용하고, 경제와 기술의 발전을 동시에 추진해야 한다.

기술을 활용하여 경제의 미래를 만들어 나가는 것이 한국 경제의 성장 및 안정적인 발전에 기여할 수 있는 것이다.

따라서, 국가는 기술 미래지향 전략을 적용하기 위한 적극적인 정책을 마련하고,

기업은 기술을 활용한 비즈니스 모델 개발에 집중해야 한다.

기술의 발전이 경제의 발전에 기여할 수 있도록, 국가와 기업이 협력하여 한국 경제의 미래를 만들어 나가야 한다.

또한, 경제의 발전을 위해서는 교육과 인재양성 또한 중요하다.

https://nownews.seoul.co.kr/news/newsView.php?id=20160217601007

경제가 발전하면서 새로운 기술이 나오면서, 기술적인 인력이 경제에서 각자의 역할을 결정짓는 중요한 역할을 하게 된다.

그래서, 교육 체계와 정책은 기술의 발전에 맞춰서 변화해야 한다.

국가는 기술의 발전에 따라 교육 정책을 수정하여, 교육의 질을 높일 수 있도록 지원해야 한다. 교육을 통해 기술을 공부하는 인력을 양성하면서, 경제의 발전에 기여할 수 있는 인력을 양성할 수 있다.

또한, 교육과 인재양성에 대한 개인의 적극적인 투자도 중요하다. 개인은 경제와 관련된 기술을 공부하여, 스스로를 개발하면서, 경제의 발전에 기여할 수 있는 인력으로 성장할 수 있다.

결국, 국가와 개인의 공동적인 노력이 필요하다. 국가는 경제의 발전을 위해 교육과 인재양성에 대한 정책을 개선하고, 개인은 스스로를 개발하면서 경제에 기여할 수 있는 인력으로 성장할 수 있다.

한편, 경제의 발전을 위해서는 경제 환경이 좋아져야 한다. 경제 환경을 좋게 만들기 위해서는, 정책과 투자, 기술 개발 등의 노력이 필요하다. 경제 환경이 좋아지면, 경제의 발전이 쉬워지고, 경제 활동이 활기차게 된다.

또한, 경제의 발전에는 국내외 투자와 교역 활동이 중요하다. 국내외 투자를 받으면, 국내 경제의 발전이 촉진되고, 교역 활동을 통해 국내 경제가 국제 경제와 통합될 수 있다.

이와 같은 방식으로, 경제의 발전을 위해서는 국가와 개인, 경제 환경과 국내외 관계를 고려해야 한다. 경제 관련 기업들도 중요한 역할을 한다. 기업은 자체 경영을 향상시키고, 기술 개발을 지속적으로 추진하여 경제에 기여할 수 있다.

경제의 발전은 모든 사람이 공포하는 노력이 필요하다. 경제의 발전을 위해서는 서로의 관심과 협력이 필요하다. 정부와 기업, 개인은 경제의 발전을 위한 정책을 수립하고, 교육과 인재양성에 대한 노력을 결코 희생하지 않아야 한다.

한국의 경제는 지금도 꾸준한 발전을 이어가고 있지만, 더욱 발전할 여지가 많다. 경제의 발전을 위해서는 정부, 기업, 개인의 공동적인 노력이 필요하다. 한국의 경제는 미래의 발전을 위한 기초가 될 것이다.

10가지 건강한 아침 식습관: 좋은 하루 시작하기

devbi — Tue, 31 Jan 2023 10:51:59 +0900

좋은 아침을 시작하는 것은 하루의 성공에 큰 영향을 미칩니다.

아침에 적절한 식습관을 가지면 기운이 넘치며, 활기차게 하루를 시작할 수 있습니다.

아래에서 소개하는 10가지 건강한 아침 식습관을 시도해보세요.

충분한 수분 섭취: 아침에 충분한 수분을 섭취하면 기운이 넘치게 하며, 수분이 부족할 경우 피로감이 증가합니다.
건강한 곡물 섭취: 아침에 건강한 곡물을 섭취하면 적절한 에너지를 공급하여 피로감을 줄여줍니다.
단백질 섭취: 아침에 단백질을 섭취하면 적절한 에너지를 공급하여 피로감을 줄여줍니다.
과일 섭취: 아침에 과일을 섭취하면 필요한 영양소를 공급하여 몸이 한결 가벼워집니다
운동하기: 아침에 운동을 하면 기운이 넘치게 하며, 피로감을 줄여줍니다.
깨끗한 물 섭취: 아침에 깨끗한 물을 충분히 섭취하면 몸의 노폐물을 제거하여 기운을 높여줍니다.
아침식사 적절히 포함하기: 아침에 김이 많은 음식을 먹지 않고, 적절한 양의 식습관을 가지면 기운이 넘치게 하며, 피로감을 줄여줍니다.
다양한 식습관 가지기: 아침에 다양한 식습관을 가지면 필요한 영양소를 적절히 공급하여 기운이 넘치게 하며, 피로감을 줄여줍니다.
체중 관리: 아침에 적절한 체중 관리를 하면 기운이 넘치게 하며, 피로감을 줄여줍니다.
긍정적인 마인드: 아침에 긍정적인 마인드를 가지면 기운이 넘치게 하며, 피로감을 줄여줍니다.

이외에도

오일과 소금: 오일과 소금을 이용한 건강한 아침 식습관
따뜻한 물 욕조: 피로를 풀고 건강한 피부를 유지하는 데 도움
마음 정리: 아침에 잠시 마음을 정리하여 신체와 마음의 편안함 회복.
노래 듣기: 기운이 없을 때 좋아하는 노래를 듣으면서 기운을 북돋아줌.
자연적인 아침 빛: 아침에 빛을 많이 받으면 시간 맞추기에 도움이 되고 기운을 북돋아줌.
아침 다이어트: 아침에 건강한 식습관을 유지하여 체중 관리와 건강 관리.
아침 휴식: 아침에 잠시 휴식을 취하면 기운이 북돋아주고 마음을 정리할 수 있음.

이 10가지 건강한 아침 식습관을 시행하면 피로를 풀고 깨어진 하루를 시작할 수 있습니다. 새로운 습관을 시작하는 것은 처음엔 어렵지만, 조금씩 꾸준히 시행하다보면 자연스럽게 건강한 아침 습관이 될 것입니다.

이더리움의 MEV (Maximal Extractable Value)

devbi — Wed, 7 Dec 2022 11:01:43 +0900

MEV의 개념은 Phil Daian이 “Flash Boys 2.0”에서 최초로 제시

저자의 동료들인 Dan Robinson, Georgios Konstantopoulos, 그리고“Ethereum is a Dark Forest” and “Escaping the Dark Forest.”의 samczsun에 의해 널리 알려지게 되었습니다.

MEV라는 개념은 암호경제학(cryptoeconomics)의 기반이라고 할 정도가 되었습니다

대체 MEV가 무엇일까요?

MEV는 채굴자가 이러한 능력으로 창출할 수 있는 최대의 이익을 말합니다.

이더리움은 MEV 매커니즘

채굴자(혹은 validator, sequencer 등)는 블록을 생성하며 어떠한 트랜잭션을 포함시킬지, 제외시킬지, 혹은 재배열(re-order)할지를 마음대로 결정할 수 있습니다.

하나의 블록 내에서 트랜잭션을 처리할 수 있는 유일한 권한을 가진 채굴자는 EVM 내 MemPool 설계로 이익을 실현 할수있습니다.

블록 당 포함될 수 있는 트랜잭션 수는 정해져 있기에 수요가 몰릴 경우 블록 생성자는 수익을 극대화하기 위해 멤풀*(mempool)에서 대기 중인 트랜잭션 중에서 가스비를 가장 많이 제출한 트랜잭션을 우선적으로 블록체인에 기록

결과적으로 블록생성과정 가운데 채굴자는 재배열,제외,포함의 권한을 가지고 MEV를 실현 시킬수있게 된다

MEV가 존재하는 이유는

블록스페이스가 한정되어 있고 (이더리움은 ~30M gas)
블록체인내 모든 활동이 투명하게 공개되어 있고
수수료 시장이 존재하며 4) 블록 생성자들이 임의로 트랜잭션 순서를 정할 수 있기 때문이다.

MEV는 어떤 영향을 미칠까?

1. Uniswap 사례를 살펴봅시다. 큰 규모의 거래가 일어나서 일시적 가격 변동(slippage)을 가져왔고, $10,000 어치의 수익 창출 기회(MEV)가 만들어진 상황입니다. 이 때 시장차액거래를 하여 실제 가격과의 괴리를 줄여주는 봇은 Uniswap 시장을 좀 더 효율적으로 만들어줍니다. 먼저 주문을 넣은 트레이더에게 해를 입히지 않으면서요. 이것은 양성(benign) MEV 트랜잭션 좋은 예시 입니다

2. 같은 거래의 다른 버전을 생각해볼 수 있습니다. 여기서는 한 차익거래 봇이 이용자의 거래를 실행되기도 전에 알아챕니다. 그리고 이용자의 거래를 “샌드위치” 공격합니다. 봇의 매수-매도 주문 사이에 이용자의 거래가 위치하도록 만드는 것입니다. 이 경우 MEV는 이용자에게 보이지 않는 세금을 뜯어내는 것과도 같습니다. 봇의 매수 주문 이후, 이용자의 주문은 인위적으로 부풀려진 가격에 체결될 것인데, 이 경우 봇은 즉각적으로 이를 되팔아서 수익을 실현할 수 있게 됩니다. 당연하게도, 채굴자들은 비용을 지불하지 않고서도 이를 실행할 수 있습니다. 이것이 악성(malignant) MEV 트랜잭션으로 불리는 사례입니다.

MEV 누적 이익

MEV는 시간이 흘러갈수록 점차 그 이익은 커져만 가고 있습니다.

종류

대표적으로 아비트라지는 프론트러닝 수법중 하나

프론트러닝(frontrunning): 수익성 높은 트랜잭션(예: 아비트라지)이 멤풀에 포착될 경우 동일한 
트랜잭션을 생성한 채 가스비만 더 높게 제출하여 기회를 가로채는 행위를 뜻한다.

백러닝(backrunning): 프론트러닝과 반대로 타겟 트랜잭션 직후에 주문을 넣어 수익을 창출하는 
행위이다. 거래 규모가 큰 트랜잭션에 의해 일시적으로 높은 슬리피지가 발생하면 MEV 봇이 그 즉시
반대 주문을 넣어 시세 차익을 챙기는 것이 백러닝의 대표적인 예시이다.

샌드위치 공격(sandwich attack): 샌드위치 공격은 프론트러닝과 백러닝을 동시에 수행하는 MEV 공격 유형이다. 
프론트러닝, 백러닝과 마찬가지로 유니스왑같은 AMM DEX에서 흔히 발생하며, 성공했을 경우 
두 차례에 결처 수익을 낼 수 있다는 것이 특징이다.

예시: MEV봇이 유니스왑에서 알트코인A를 대량 구매하는 주문을 포착하면 
곧바로 동일한 트랜잭션을 생성하여 주문자를 프론트러닝한다. 
이후 기존 주문자가 더 높은 가격에 A를 구매하면 즉시 구매하였던 토큰을 매도하여 시세 차익을 챙긴다.

MEV는 좋은 영향 보다 나쁜 영향이더 많다

※ 개인적으로 아비트라지는 DEX 운영에 있어 좋은 영향이라 생각한다 하지만 수많은 봇들은 당연히 네트워크 문제를 일으키므로 화이트리스트를 적용시킨 아비트라지가 있다면 어떨까 생각해본다

1. 유저 경험(UX) 훼손 및 수익 갈취

프론트러닝, 샌드위치 공격과 같은 악의적인 MEV 활동은 유저들에게 많은 기회를 빼앗는다
Bot이 있는 이상 일반 사용자에게 있어 기회는 돌아가기 힘들다

2. 네트워크 과부하 발생

PGA(블록스페이스 경매) 활동으로 인한 과도한 경쟁은 네트워크 과부하및 가스비 폭등

3. 네트워크 불안성 조성

Re-org는 긴체인의 법칙으로 진행된다 악의적인 MEV는 과거의 트랜잭션을 복사하여 실행시킨뒤 Re-org를 진행시켜 원하는 수익을 실현시킬수있다, 보통 규모가 비교적 작고 보안이 약한 블록체인에서 발생할 가능성이 높음
대표적으로 Time bandit attack

이더리움 2.0은 MEV에 어떤 영향을 끼칠까?

결론부터 말하자면, 오히려 MEV가 활발히 활동할것이다

PoW 합의 알고리즘에서는 채굴자들이 랜덤으로 선출되며, 그 누구도 다음 채굴자가 누가 될 지 100% 확신할 수 없다. 반면, 이더리움 PoS 전환 이후에는 블록 생성자로 선정될 경우 2epoch 동안 함께 블록을 생성할 검증자가 누구인지 파악이 가능하여 오히려 MEV를 기회를 더 많이 포착할수있게 한다
PoS 전환은 블록 생성에 따른 ETH 보상을 90% 가까이 낮춰 검증자 노드들로 하여금 MEV 활동을 장려하는 결과가 발생할 수도 있다.
EIP-1559 이후 베이스 수수료(base fee)가 소각되고 있기 때문에 검증자 노드들의 몫은 더욱 줄어들었다

결과적으로 인플레이션을 대폭 감소시켜 ETH 가치를 보존하고 끌어올리는데 기여하지만, 반대로 블록 생성 보상이 대폭 줄어든다는 것을 뜻하기도 한다. 이에 따라 검증자들은 줄어든 보상을 충당하기 위해 MEV 활동을 더욱 공격적으로 펼치게 될 여지가 있다.

해결책은 무엇이있을까?

mev 솔루션으로 많이 사용되는 Flashbot(경매 서비스)

Flashbot

트랜잭션 정보가 모두에게 공개된 멤풀이 아닌 별도의 프라이빗 트랜잭션 풀을 운영하고
전통 경매 방식 중 하나인 최고가격입찰제(first price sealed bid auction)에 기반한 비공개 블록스페이스 입찰(sealed bid blockspace)을 진행한다는 특징이 있다.

MEV Boost

플래시봇과 동일한 서비스이나, searcher와 relay 사이에 builder라는 새로운 역할군이 추가되었다는 것이 차이점이다.

근본적인 또 다른 해결책?

Batching trading

암호화폐 거래소의 호가창에서 단일 배치 내 여러 거래를 한꺼번에 묶어 일괄적으로 처리하는 방식을 의미한다.
각 블록의 결제 가격이 같도록 토큰쌍들의 가격을 정확히 매길 수 있는 가격결정 매커니즘으로 활용될 수 있다.

디파이 시스템에서 채굴자 또는 검증인(validator)은 트랜잭션을 재배치할 권한을 갖는데, 배칭옥션은 그러한 권한을 없애는 역할을 한다. 배칭옥션에서 채굴자들은 주문과 상관없이 트랜잭션을 실행해야 하기 때문이다. 배칭옥션의 결제 가격은 균일하므로 거래의 주문 순서는 가격에 아무런 영향을 미치지 않는다.

배칭옥션은 프로토콜을 기반으로 한 댑의 개발을 촉진함으로써 사용자들에게 다음과 같은 향상된 트레이딩 기법을 제공한다.

가스 비용 없는(gasless) 제출 또는 사용자들이 서명된 메시지를 통해 오프체인 주문을 제출하는 것
트레이더가 다르더라도 동시에 발생한 거래에 대해 동일한 가격을 적용하는 것
외부의 제3자 유동성 풀에 의존하지 않고 '욕망의 일치(coincidence of wants)'에 따라 사용자들을 직접 매칭하는 것

Reference

https://research.paradigm.xyz/MEV

https://xangle.io/insight/research/635f8c1f6c4f32e243e4349c

스마트 컨트랙트 시큐리티 패턴

devbi — Wed, 2 Nov 2022 18:16:36 +0900

이전 포스팅에서

Checks Effects Interaction, Mutex Pattern

알아보고 재진입 공격에 대해서 포스팅을 하였습니다

이번엔 그밖에 다양한 시큐리티 패턴에 대해 알아보고자 합니다

1. Emergency Stop Pattern

- 블록체인에 배포된 스마트컨트랙트는 수정이 불가능합니다

그래서 예기치 못한 버그로 인해서 큰 피해를 줄 수 있는데 Emergency Stop Pattern은 특정 함수들이 실행되지 않도록 제어할 수 있도록 프로그래밍하는 패턴입니다. 쉽습니다

contract EmergencyStop is Owned { 
  bool public contractStopped = false; 
  modifier haltInEmergency { 
    require(contractStopped) 
    _; 
  } 
  modifier enableInEmergency { 
    require(!contractStopped) 
    _; 
  } 
  function toggleContractStopped() public onlyOwner { 
    contractStopped = !contractStopped; 
  } 
  function deposit() public payable haltInEmergency { 
    // some code 
  }
  function withdraw() public view enableInEmergency { 
    // some code 
  } 
}

컨트랙트의 Owner만이 function의 제어권을 조절할수있습니다.

haltInEmergency로 함수를 제어합니다 Owner만이 contractStopped의 변수값을 수정할 수 있습니다.

2. Speed Bump Pattern

- 과속 방지턱 패턴은 이름에서 알 수 있듯이 보행자를 보호하기 위한 안전장치입니다

Speed Bump Pattern은 특정 함수를 실행하기 위해서 의도적으로 시간을 지연시키거나 한 번에 인출할 수 있는

금액에 제한을 두는 패턴입니다.

이렇게 하는 이유는 특정 함수를 다수의 사용자가 무제한적으로 호출함으로 컨트랙트에 이상이 생기는 것을 방지하기 위함입니다.

contract SpeedBump { 
  struct Withdrawal { 
    uint amount; 
    uint requestedAt; 
  } 
  mapping (address => uint) private balances; 
  mapping (address => Withdrawal) private withdrawals; 
  uint constant WAIT_PERIOD = 7 days; 
  function deposit() public payable { 
    if(!(withdrawals[msg.sender].amount > 0)) {
      balances[msg.sender] += msg.value; 
    }
  } 
  function requestWithdrawal() public { 
    if (balances[msg.sender] > 0) { 
      uint amountToWithdraw = balances[msg.sender]; 
      balances[msg.sender] = 0; 
      withdrawals[msg.sender] = Withdrawal({ amount: amountToWithdraw, requestedAt: now }); 
    } 
  }
  function withdraw() public {
    if(withdrawals[msg.sender].amount > 0 && now > withdrawals[msg.sender].requestedAt + WAIT_PERIOD) { 
      uint amount = withdrawals[msg.sender].amount; 
      withdrawals[msg.sender].amount = 0; 
      msg.sender.transfer(amount); 
     } 
  } 
}

deposit을 통해 입금한 Balances를 인출하기 위해서는 withdraw() 수행이 가능합니다

인출하기위해서는 두 가지 조건이 필요합니다

requestWithdrawal() 호출을 통해서 예약을 하고, WAIT_PERIOD의 인출시간이 지나야지만 최종적으로 인출이 가능합니다.

3. Rate Limit Pattern

- 위 패턴은 함수를 호출할 수 있는 빈도를 제한하는 패턴입니다.

아래의 코드는 함수 F가 한번 실행이 되면 1분이 지나야 만 다시 실행할 수 있도록 구현되어 있습니다.

contract RateLimit { 
  uint enabledAt = now; 
  modifier enabledEvery(uint t) { 
    if (now >= enabledAt) { 
      enabledAt = now + t; 
      _; 
    } 
  } 
  function f() public enabledEvery(1 minutes) { 
    // some code 
  } 
}

4. Balance Limit Pattern

- 스마트 컨트랙트 내의 잔액의 최댓값을 설정하여, 최대값 이상으로 컨트랙트로 금액이 보내지는 것을 막는 패턴입니다.

contract LimitBalance { 
  uint256 public limit; 
  function LimitBalance(uint256 value) public { 
    limit = value; 
  } 
  modifier limitedPayable() { 
    require(this.balance <= limit); 
    _; 
  } 
  function deposit() public payable limitedPayable { 
    // some code 
  } 
}

위 코드는 LimitBalance 함수를 통해 컨트랙트에서 보유할 수 있는 최대 잔액을 설정한 후, 보유한 잔액이 설정된 최대 잔액보다 작을 때만 deposit 함수를 실행할 수 있도록 구현되어 있습니다.

위와 같은 패턴들은 예기치 못하는 상황을 사전에 방지할 수 있으며 스마트 컨트랙트의 안정성을 높여주는 패턴이므로

꼭 염두에 두자

다음엔 Maintenance Pattern에 대해서 알아보자

Fallback, Receive 그리고 재진입 공격

devbi — Sun, 30 Oct 2022 15:37:19 +0900

Fallback, Receive 함수에 대해 알아보겠습니다

Fallback

- 대비책 함수

- 무기명 함수 즉 이름이 없는 함수

- external과 payable이 필수

어떤 경우에 사용이 되는가?

- 스마트 컨트랙트가 이더를 받을수 있게함

- 이더를 받고 난 후 어떠한 행동을 취하게 할 수 있음

- Call 함수로 없는 함수가 불려질떄, 어떠한 행동을 취하게 할 수 있음

0.6 이전 버전의 Fallback은 아래와 같이 사용

function() external payable {
    
}

0.6 이후 fallback

Fallback은 Recevie와 Fallback 두가지 형태로 나뉨

Receive: 순수하게 이더만 받을때 작동

Fallback : 함수를 실행하면서 이더를 보낼때, 불려진 함수가 없을 때 작동함

1. 불려진 함수가 특정 스마트 컨트랙트에 없을때 fallback 함수가 발동 합니다

fallback() external {
   
 }

- 위 형태는 call(0.6.0 이후)을 통해 호출하는 컨트랙트의 함수 이름이 없을때 사용되는 형태입니다

2. 이더를 받고 나서도 fallback 함수가 발동

fallback() external payable {
   
}

receive() external payable{
    
}

- 위와 같이 payable을 추가해줘야한다

Fallback, Receive을 호출한 대상의 msg.sender는 누구일까?

A 컨트랙트에서 B컨트랙트로 Call 호출을 하여 Fallback, Receive 함수가 동작을 했을때

msg.sender는 A컨트랙트로 지정되어있다

2019년 이스탄불 하드포크 이후 0.6.0이후 Fallback, Receive를 사용을하니 자신에게 필요한 방법을 사용하면 된다

주의할건 단순히 이더를 전송하는 Send, Transfer 함수는 2300의 고정 gas 소모때문에 원하는 로직 구현이 힘들어

Call을 권장하고 사용되고있다

하지만 Call은 재진입 공격 문제가있어 주의가 필요하다

왜 Call을 사용하면 재진입 공격문제가있는가?

 fallback() external payable {
     emit JustFallbackWIthFunds(msg.sender, msg.value,"JustFallbackWIthFunds is called");
}

위 컨트랙트를 살펴보면 Fallback이 이벤트를 실행시킨다

이때 호출을 하면 revert가 발생하게 된다

send, trasfer등을 사용했을때 그래서 재진입 공격에 필요한 로직을 구성할수가없다

하지만 Call은 가변길이의 가스소모를 가지고있어 재진입 공격에 필요한 로직을 구성할수있는 External Call을 할수있기 떄문에

반드시 시큐리티 코딩이 필요하다

재진입 공격 방지 (Re-Entrancy)

devbi — Fri, 28 Oct 2022 18:17:41 +0900

External call에 이어서 관련된 재진입 공격에 대해 알아봅시다.

이더리움의 DAO 해킹 사건이후 가장 요구되는 기본 보안 사항이다

보통 재진입 공격같은 경우 External Call의 address.call에 의해 발생한다

DAO 사건또한 이러한 문제 떄문에 발생한 이슈입니다

1. 단일 함수에 대한 재진입 입니다

// INSECURE
mapping (address => uint) private userBalances;

function withdrawBalance() public {
    uint amountToWithdraw = userBalances[msg.sender];
    (bool success, ) = msg.sender.call.value(amountToWithdraw)(""); // At this point, the caller's code is executed, and can call withdrawBalance again
    require(success);
    userBalances[msg.sender] = 0;
}

위 코드 블록은 6번째줄과 8번째 줄에 문제가있습니다

Checks effect Interaction 패턴에 위반되는 코딩 스타일입니다

첫번째 check하지 않았고

두번째 effect를 수행하지 않고 Interaction 을 수행 그리고 External call에대한 예외 처리만 하였습니다

위와 같은 방식의 스타일은 사용자의 잔액은 함수가 끝날떄까지 0으로 설정되지 않으므로 두번째 호출부터 계속 성공하여 추가적인 잔액을 인출 할수있습니다

mapping (address => uint) private userBalances;

function withdrawBalance() public {
    uint amountToWithdraw = userBalances[msg.sender];
    userBalances[msg.sender] = 0;
    (bool success, ) = msg.sender.call.value(amountToWithdraw)(""); // The user's balance is already 0, so future invocations won't withdraw anything
    require(success);
}

위 방식은 내부 작업이 모두 완료된후에 외부 함수를 호출하는 방식으로 수정된 방식이다

가장 중요한건 순서 바뀌어도 방지할수있다는것이다

추가적으로 하나더 패턴을 추가하자면

mapping (address => uint) private userBalances;

function withdrawBalance() public {
	require(userBalances[msg.sender] > 0,"Checks pattern") // 4번 라인
    uint amountToWithdraw = userBalances[msg.sender];
    userBalances[msg.sender] = 0;
    (bool success, ) = msg.sender.call.value(amountToWithdraw)(""); // The user's balance is already 0, so future invocations won't withdraw anything
    require(success);
}

기존 Checks effect Interaction 에서 Checks를 넣는것이다

Effects를 적용하기 앞서 호출자의 올바른 요청을 하고있는지를 확인하는것이다

또 다른 방법으로는 아래와 같은 방법을 사용 할 수 있다.

bool private reentrancyLock = false;
modifier nonReentrancy() {
    require(!reentrancyLock);
    reentrancyLock = true;
    _;
    reentrancyLock = false;
}

위와 같은 방식은 Mutex 솔루션이라고 한다, Checks에 속한다

해당 modifier를 바인딩한 함수는 External Call로 인한 반복적인 재귀호출의 진입을 막을수가있다

Mutex 솔루션은 단일 트랜잭션 공격에대해 강력하게 대응할수있지만 단점이 존재합니다

협업에 있어 해당 솔루션은 개발하는데 까다로운 조건이 될것입니다

아래는 안전하지않은 Mutext 솔루션 입니다

// INSECURE
contract StateHolder {
    uint private n;
    address private lockHolder;

    function getLock() {
        require(lockHolder == address(0));
        lockHolder = msg.sender;
    }

    function releaseLock() {
        require(msg.sender == lockHolder);
        lockHolder = address(0);
    }

    function set(uint newState) {
        require(msg.sender == lockHolder);
        n = newState;
    }
}

위와 같은 형태는 현재의 컨트랙트 사용자가 lockHolder로 사용되고 컨트랙트를 점유하고있음을 보여줍니다

하지만 공격자 입장에서는 해당 계약을 완전히 잠글수있는 구조를 가지고있기에 보안의 취약함이 드러납니다

getLock을 통해서 lockHolder를 점유한 상태에서 releaseLock()을 실행하지 않을것입니다

그렇게 되면 프로그램은 교착상태에 빠져 계약을 사용할수없게 됩니다

지금까지 DAO 사건이후의 재진입 공격에대한 솔루션과 대책을 알아 봤습니다

기본적은 CEI 패턴을 적용을 하였을경우 단일 트랜잭션 공격에대한 재진입 공격을 막을수있습니다

이후 포스팅에서는 다른 형태의 공격 유형으로 같은 블록에서 트랜잭션 순서 자체가 쉽게 조작을 방지하기위한

솔루션을 알아보겠다

External Call 보안

devbi — Fri, 28 Oct 2022 12:15:17 +0900

모든 체인의 Contract는 보안성이 중요하다 순식간에 자본금이 사라질수있기 떄문이다.

시큐리티 코딩은 기본적으로 스마트컨트랙트 개발자라면 알아두어야할 사항이라 생각하여 포스팅을 시작한다

External Call 신뢰성

- External Call 잠재적인 위험에 노출되어있다고 생각해도 무방 하다.

- External Call은 해당 계약및 의존하는 다른 계약에서 악성 코드를 실행 할 수 있기 때문이다.

- 그래서 모든 External Call은 잠재적인 보안 위험으로 취급되어 최대한 외부호출을 제거하거나

권장 사항을 사용하여 위험을 최소화 해야한다

1. 신뢰할 수 없는 계약의 표시

- 가장 먼저 외부 계약에 관련해서 상호 작용이 잠재적으로 안전하지 않다는 것을 분명히 하자

// bad
Bank.withdraw(100); // Unclear whether trusted or untrusted

function makeWithdrawal(uint amount) { // Isn't clear that this function is potentially unsafe
    Bank.withdraw(amount);
}

// good
UntrustedBank.withdraw(100); // untrusted external call
TrustedBank.withdraw(100); // external but trusted bank contract maintained by XYZ Corp

function makeUntrustedWithdrawal(uint amount) {
    UntrustedBank.withdraw(amount);
}

- UntrustedBank에 대한 인출함수는 신뢰할수없는 호출이라 명시되어있고

- TrustedBandk에 대한 인출함수는 신뢰할수있는 기업의 라이브러리를 사용하여 적용(xyz. 금융 플랫폼간의 통합을 구축하는 블록체인 개발 회사)

2. 외부 호출후 상태 변경 방지

- raw call, (somAddress.call()), Contract Call을 사용하면 악성코드가 실행될 수 있다고 가정 합니다

- 이 문제점은 악성코드가 제어흐름을 가로채고 재진입으로 인한 취약점으로 이어질 수 있다는점 입니다

- 신뢰할 수 없는 외부 계약을 호출 하는 경우 상태 변경(value)을 반드시 interactions 발생하기전에 변경하기를 바란다 (Checks-Effects-Interactions Pattern)

- Checks-Effects-Interactions Pattern?

Contract 작성시 가장 기본이 되어야하는 Base 패턴이다

공식 문서에서도 알려지지 않는 계약로 인한 재진입 문제를 해결하기위한 패턴입니다

1. 검사

2. 영향

3. 상호작용

각 함수는 위 3가지 요소의 순서를 반드시 지키길 권장하며 맨위와 같은 문제들을 방지 할 수 있습니다

pragma solidity 0.8.13;


contract reentrancyVictim{
    mapping(address => uint256) public balances;
    uint256 public contractBalance;
    
    function payIn() public payable{
        balances[msg.sender] += msg.value; 
    }
    
    function withdraw() public payable{
        require(balances[msg.sender] > 0, "Insufficiant balance");
        payable(msg.sender).call{value: balances[msg.sender]}("");
        balances[msg.sender] = 0;
    }
    
    function updateContractBalance() public{
        contractBalance = address(this).balance;
    }
}

위 코드는 Checks-Effects-Interactions Pattern 적용 되지 않았을때 코드이다

widthdraw를 보면 밸런스를 체크하고 msg.sender call 통해서 이더리움을 보내고 상태변수를 바꾸는걸 볼수있다

순서를 보면

1. Checks

2. Interactions

3. Effects

형태를 띄고있다

Checks-Effects-Interactions Pattern 를 적용했을때 아래의 코드와 같다

 function withdraw() public payable{
        
        // check
        require(balances[msg.sender] > 0, "Insufficiant balance");
        
        // effect
        uint256 payBalance = balances[msg.sender];
        balances[msg.sender] = 0;
        
        // interaction
        (bool success, bytes memory data) = payable(msg.sender).call{value: payBalance}("");
        if(!success){ // catch the case where the send was unsuccesful
            balances[msg.sender] = payBalance;
        }
}

1. Checks 동일하다

2. effect

- 기존과 다르게 상태 변수를 먼저 초기화 시키고 임시변수를 통해서 해당 value를 바인딩하여 사용한다

3. interaction

- 똑같지만 성공여부를 return 받는다 이후 실패한경우를 catch하여 변수를 재할당 해준다

가장 중요한 interaction

effects가 실행되지않고 interaction이 실행되면 재귀 함수 호출되므로 더 많은 잔고를 인출해 나갈수가 있습니다

항상 interaction을 마지막에 실행시킨다는것을 잊으면 안된다

3. Transfer(), Send() 대신 Call() 사용

먼저 Transfer, Send의 특징을 알아보자

- Send()

2300gas를 소비, 성공여부를 true, false를 리턴 payment 가 제대로 이루어지면 fallback(), receive() 호출

- Transfer()

2300gas를 소비, payment가 이루어지면 fallback, receive가 호출됩니다 실패조건은 두가지이며 아래와 같다

1. 송신자 컨트랙트 balnce가 충분하지 않을때

2. 수진자 컨트랙트에서 payment를 rejects 할때

Send, Transfer의 공통점은 2300의 낮은 가스를 소비한다는 겁니다

이 계약은 EOA간의 단순한 전송만을 위해 설계되었고 동작하지만 CA간의 수행시 복잡한 연산을 처리하는데는 부족한 GAS를 지불하기 떄문에 Call 방식을 추천합니다

- Call()

이름으로 함수를 호출하고 Ether를 보낼수있는 방식입니다 2019년 12월부터 권장된 방식입니다

가스는 가변하고 지정할수있기에 다양한 로직을 처리 할 수 있습니다

하지만 수신자의 계약이 Call문이 주어진 곳에서 함수를 다시 호출하여 재진입 공격을 허용 합니다

반드시 발신자의 계약에서 재진입 공격으로 인한 계획된거 보다 더 많은 자금 유출에 신경 써야합니다

반드시!!!!!! 방지 합시다!!! 앞에서 설명한 Checks-Effects-Interactions Pattern 패턴을 사용하면 방지 할수 있겠조?

재진입 공격에대한 방지방법은 따로 포스팅 해보도록 하겠습니다

4. 외부 호출시 오류 처리

Solidity는 원시 주소에서 작동하는 raw call들을 제공합니다, adress.call(), address.callcode(), address.delegatecall(), address.send() 등 이러한 호출의 공통적인 특징은 예외를 throw하지 않지만 false호출에 예외가 발생하면 반환 됩니다 그래서 저수준 호출 방법을 사용하기로 선택했다면 반환 값을 확인하여 호출이 실패할 가능성을 처리하 합시다

아래 방법은 예시 입니다

// bad
someAddress.send(55);
someAddress.call.value(55)(""); // this is doubly dangerous, as it will forward all remaining gas and doesn't check for result
someAddress.call.value(100)(bytes4(sha3("deposit()"))); // if deposit throws an exception, the raw call() will only return false and transaction will NOT be reverted

// good
(bool success, ) = someAddress.call.value(55)("");
if(!success) {
    // handle failure code
}

ExternalContract(someAddress).deposit.value(100)();

5. delegatecall 신뢰할수 없는 컨트랙트 주소에 사용하지 마세요

delegatecall의 사용성은 굉장히 범용적입니다 A->B->C A의 호출자는 B를 실행했지만 B의 코드에서 마치 C의 함수가 B의 것인것마냥 실행시킵니다 이때 호출 주소를변경 시킬수있기에 안전하지 못할수있습니다

아래는 잘못된 코딩으로 잔액 손실이 발생하는 예제 입니다

contract Destructor
{
    function doWork() external
    {
        selfdestruct(0);
    }
}

contract Worker
{
    function doWork(address _internalWorker) public
    {
        // unsafe
        _internalWorker.delegatecall(bytes4(keccak256("doWork()")));
    }
}

해당 문제는 손쉽게 이해할수있습니다

신뢰되지않는 _internalWorker의 주소의 doWorker() 호출로 인해 강제 계약의 파기되는 모습을 볼수있습니다

절대적으로 신뢰할수있는 판단이 들거나 그러한 조건을 갖추었을때 delegatecall을 사용해야합니다

다음엔 재진입 방법에 대한 솔루션을 제시 하겠습니다

채굴 (Mining)

devbi — Mon, 17 Oct 2022 18:38:58 +0900

블록체인에서 흔히 '채굴' 이라는 단어는

블록체인 네트워크에 노드로 트랜잭션을 검증하여 분산원장을 기록하고 보상으로 암호화폐를 얻는 것을 말함

여기서 블록체인 네트워크에서 새로운 블록을 생성하고 그 대가로 암호화폐를 지급받는 노드들이 '채굴자' 라고 얘기하조

그럼 우리 노드들은 채굴을 왜하는걸까? (당연히 돈이 되니깐 하조..ㅋㅋ)

이익이 되니깐 하는거다 이건 비트코인 게임 이론이랑도 연관이 있다

대표적으로 비트코인의 Pow에 대해 알아봅시다

이 노드(채굴자)는 어떤일 을 하나면 (이것도 일이조)

- 네트워크 동기화 : 새로운 노드가 비트코인 네트워크에 합류하면, 다른 노드에게 과거의 블록들을 요청해 블록체인을 다운로드 할수있게 해주조

- 트랜잭션 검증 : 새로운 트랜잭션을 수신한 노드는 반드시 해당 트랜잭션이 올바른 트랜잭션인지 검증하는 과정을 거쳐요

- 블록 유효성 검사 : 채굴자와 풀노드는 특정 규칙에 따라 수신한 블록을 평가? 하여 유효성 검사를 합니다

(풀노드? 란게 뭐냐면 블록체인의 가장 첫 번째 블록부터 지금까지의 블록정보를 모~~~~~두 가지고 있느 노드를 말합니다

그외로 라이트노드가 있는데 SPV라고 블록체인 거래 데이터가 없어서 다른 풀 노드에게 자료를 요청해서 거래를 진행하는걸 말합니다 아예없는건 아니고 블록체인에 헤더 요약본을 가지고있습니다)

- 새로운 블록 생성 : 채굴자가 네트워크에 브로드캐스팅된 트랜잭션의 유효성을 검사 하는 행위

- 작업 증명 POW 수행 : 채굴 과정의 핵심입니다, 채굴자가 해시 퍼즐을 풀어서 유효한 블록을 찾는 과정이조

HOW? 블록헤더에 Nonce라는 값이 있는데 이값을 채굴자가 계속 바꿉니다, 그래서 이미 결정된 목표값보다 작을 때까지 반복하는거조 그렇게 먼저 빨리 찾으면? 새로운 블록을 생성하고 비트코인을 지급받고 돈을 벌게됩니다...!

* 블록 헤더에 있는 논스와 트랜잭션 논스는 다릅니다

* 비트코인 논스와 이더리움 논스의 차이입니다

- 보상 수령 : POW 퍼즐을 풀면 결과를 브로드캐스팅하고 다른 노드들은 그 결과를 검증하고 블록을 승인하게 되며 당사자는 bitcoin을.. 지급받습니다!!

이렇게 생각보다 노드는 하는일이 많습니다

돈을 벌기위해 하나의 체인에서 자신의 컴퓨팅 파워를 소모하는것이조

우리도 비트코인 노드가 될수있을까?

- 결론부터 말하자면 불가 하다 아래 그림을 살펴 보자

비트코인 해시레이트

위 그림은 '해시율' 이라고 초당 해시 계산 개수 비율을 말하는데 쉽게 말해서 블록을 찾기 위해 비트코인 네트워크상의 채굴자들이 해시를 계산하는 속도를 말합니다

2010년부터 2016년 까지는 인기가 없어서 개인 CPU 비트코인을 채굴했는데 2018년이되서 전문 마이닝풀, ASICs 라는게 도입이 되면서 마치 비트코인시세처럼 떡상하게 되조

이 얘기는 비트코인 난이도가 급격하게 증가했다는 얘기에요

막강한 컴퓨팅 파워를 가지고 병렬로 작업하지않는 이상 우리는 코인을 획득할수없을거에요 아마 전기세만 기부만 하게되는거조

우리는 그러면 채굴풀(Mining Pool) 에 대해 알아볼 필요가있습니다

앞서 잠깐 얘기를 했는데, Pool이 라는게 우리나라 노조 같은거 ..네 맞아요 노조 입니다

여기서 생각할게 이 노조가 왜 생겼냐에요

앞서 그래프를 보면 알수있듯이 기존에 비트코인 채굴자들은 개인PC로 퍼즐을 풀어서 비트코인을 보상으로 지급받았습니다

그런데 마이닝 기술이 발전하면서 해시레이트가 급격하게 증가 하면서 기존의 개인 해시파워로는 보상을 받을수없게된거조

그래서 낮은 해시파워를 가진 사람들끼리 뭉쳐서 보상을 나눠가지는게 이 채굴풀 이라는겁니다

이제 몇가지 채굴 방법에 대해 알아보자

POW, POS, DPOS

POW

POW는 앞에서 설명했듯이 해시퍼즐을 풀어서 보상을 지급합니다

하지만 동시에 블록을 채굴하는경우가 생기면?

실제로 그러한 경우 고아블록이 생기게 됩니다

고아블록이란 동시에 블록을 두개를 생성하여 블록이 분기되는걸 말합니다

출처 - 해시위키

결과적으로 체인의 길이가 가장긴것을 선택하여 블록이 쌓이지만 그렇지못한 고아블록이 처리될려면

비트코인은 거래 확정을 3~5개 이후 확정되게끔 설정을 해놔서 해결을 합니다

이더리움 같은경우 POW 시절에는 고스트 프로토콜을 사용하여 위 문제를 해결했습니다

POW의 장점은 높은 보안성이라는겁니다

블록체인의 취약점인 51% 공격을 쉽게 방어합니다

POW의 단점은 채굴난이도가 높아지면서 개인 채굴자는 채굴할 수 없는 수준까지 도달한다는겁니다

그리고 채굴을 위해 사용되는 고사양 장비와 과도한 전력 소모는 높은 탄소를 배출하고 환경오염까지 영향을 미치게 됩니다

POS

POS는 암화화폐를 보유하고 있는 지분율에 비례하여 의사결정 권한을 주는 합의 알고리즘 입니다

POW의 컴퓨팅 파워 낭비문제로 지분이라는 개념이 나왔조 즉, Staking 한 자산을 통해 블록을 생성하는 메커니즘 입니다

주주 총회에서 주식 지분율에 비례하여 의사결정 권한을 가지는 것과 유사합니다

POS의 장점을 빠르게 알아보면

1. POW에비해 환경친화적

2. 인센티브에 대한 강한 동조및 지지

3. 채굴 풀의 중앙집중화를 해결

이정도가 있습니다, 전부다 POW의 문제점을 해결하기위해 만들어진 느낌이조

그렇다면 POS의 단점은 무엇일까요?

장점을 뺀 모든 문제에 불안정하다는 겁니다. 그리고 POS는 암호화폐 보유량에 비례하여 신규 자금을 배당하는데 그 뜻은 자산이 많은 사람한테 자금이 집중된다는 말입니다.

가장 큰 문제는 Nothing at Stake Problem 입니다

즉, 위험에 노출되지 않는 문제를 뜻하는데, 블록 작성자가 네트워크 분기가 될 때 위험에 처하지 않는다는 뜻입니다

말이 재밌는게 예를들어 회사 사장님을 떄려도 직장을 다닌다는 재밌는 비유가 있습니다

우리가 회사 사장님을 때리지않는 이유는 직장에서 해고 당할 위험에 노출될 수 있기 떄문이조

또 다른 예 로는

POS방식은 모든 노드가 제한 없이 여러 블록에 자신의 지분을 증명할 수 있기 떄문에

만약 하나의 거래에서 서로 다른 거래내용이 발생한 경우 많은 지분을 가진 노드가 공격을 목적으로 두 개의 블록에 모두 증명해놓고, 거짓인 체인도 참인 것처럼 길게 체인을 형성시킬 수 있습니다.

여기서 새로 참여한 검증자 즉 밸리데이터는 어느 것이 정당한 블록체인인지 알 방법이 없습니다.

그래서 새로 많은 지분을 사들여 검증에 참여하는 노드가 거짓인 블록체인에 증명 해버릴 경우 제대로 된 거래를 한 사람은 모두 공격에 당하는 꼴이 되는거조.

이더리움은 이러한 문제를 해결하고 Pos로 전환했습니다

그것은 캐스퍼 프로젝트이고 기존 Pos에서 악한 행위를 하는 검증인들을 처벌할수있는 기능이 탑재되어있습니다

위와 같은 NSP 공격시 Staking된 자산을 모두 몰수당하는걸 의미 하조.

Dpos

위임 지분 증명입니다 대표적으로 EOS가 선택한 방법이조

암호화폐 소유자들이 각자의 지분율에 비례하여 투표권을 행사하여 자신의 대표자를 선정하고, 선정된 대표자들끼리 합의하여 의사결정을 내리는 합의 알고리즘 입니다.

지분 증명이 자산을 가진 사람들이 전부 참여할 수 있는 방식이라면, 위임지분증명은 특정 인원에게만 지분 증명(Pos)을 할 수 있도록 권한을 위임하는 것입니다.

재밌는건 POS에 대한 문제와 비판으로 DPos가 탄생했다는거조

위임지분증명은 지분증명 방식과 달리 누구에게나 대표자가 될 기회가 주어지지 않습니다

대표자가 되기 위해서는 투표를 거쳐야 하며, 이떄 명칭이 바뀌는데 투표를 통해 선출된 사람을 대표자라고 합니다

선출된 대표자들은 블록을 생성하고, 블록을 확정하기 위해선 2/3 이상의 승인이 필요합니다.

DPos의 장점은 무엇일까요?

1. 소규모 참여자도 이득을 볼 수 있다.

2. POS보다 거래속도가 빠르다

그렇다면 단점은?

- 네트워크 보안, 대표자의 수 입니다

이둘의 단점은 공통적인 부분에서 나옵니다.

가장 먼저 블록체인의 보안은 탈중앙화에서 나오는데 대표자들의 수가 제한되니 보안에 취약할수밖에 없습니다. 또한 외부 공격에 강한 이유가 블록체인은 익명성 떄문인데 대표자로 선출되면 대표자에 대한 정보를 밝혀야 한다는 딜레마가 있조.

대표자의 수가 일정하니 상대적으로 중앙화가 이루질수 있기 떄문에 암호화폐를 보유하고 있는 사람들의 수가 많아질수록 네트워크가 커질수록 대표자의 수는 늘어나야만 합니다

그러면 속도의 장점을 잃게되는 문제는 겪게 됩니다

클레이튼의 합의 메커니즘은 다음에..!!

[Team Project] Final

devbi — Tue, 4 Oct 2022 11:17:59 +0900

# 4주간의 여정

4주라는 시간이 나에겐 길게 느껴지지 않았었다, 어떤 프로젝트를 했었을때 4주는 기본적으로 개발만 완료된 상태였다

하지만 마지막 팀프로젝트에서의 4주는 개발이 완료되고 Minimum 한 기능이 완료되고 나서 Advance한 기능들 이후 서비스에서 필요한 예외 처리, 시나리오 테스트 이후 보완 등 지속적인 장애에 관련된 부분을더 신경 쓸수있었다

팀프로젝트의 가장큰 장점은 역시 퍼포먼스인거같다 서로 의지 하고 믿으면서 도움을 구했을때 문제가 생겼을경우 빠르게 문제를 해결할수있는 창구가 되기도 하고 모듈별로 개발하여 합치는 GIT의 특성떄문에 프로젝트의 완성도가 빠르게 높아짐을 느낄수가있었다

확실히 개인으로 프로젝트를 진행하던 나한테 팀이라는게 얼만나 중요한지 깨달았고 그파워가 프로젝트의 완성도와 디테일의 수준을 너무 큰차이를 만든다는게 느껴졌다 에자일 방식으로 진행하던 우리팀은 믿고 서로 의지 할 수있었기에 기한내에 프로토타입이라고 내놓을수 있는 수준의 완성도를 만들게 된거같다

# 프로젝트 소개

JMT는 Enjoy Maple NFT의 약자?긴 하다 우리가 흔히하는 ~~존맛탱?~~으로 오해하지 마시길...

초기 기획은 ERC20, ERC721, ERC1155를 다양하게 사용하는 게임 목표로 시작되었는데 이후 팀 회의를 통해서

토크노믹스가 필요했고 게임의 재화 유통과 사용을 위해 디파이를 접목하게 되었다

# 나는 무엇을 했는가?

우리 프로젝트에서 서브 과제중 하나가 팀원 모두가 Contract 코드를 작성하고 경험하는것인데 블록체인 프로젝트를 시작하고나서 Contract 코드를 제대로 작성한 경험이 없어서 반드시 이번기회에 Contract 작성에 대한 이해도와 깊이를 늘리고 싶어 Contract 지원파트에 열심히 자기 PR을 한거같다... 결과적으로 JMT 프로젝트에서 중요한 JMT Token, vJMT Token,

Swap Contract, Router Contract, Liquidity Pool Contract, Staking Contract 등 다양한 컨트랙트를 직접 개발했다

# 귀여운 Token들 소개

ERC20, 721, 1155  다 사용했다

메이플 스토리 에셋을 사용해서 굉장히 귀욥?다 내가 개발한건 ERC20과 디파이 컨트랙트다

# 토큰 이코노미 그게 뭔가?

말그대로 "토큰 경제" 이해하기 처음엔 어려운데, 직접 프로젝트를 하면서 어떤 플로우를 가지고있고 어떤걸 고려해야하는지 알수있는 영역이다 어쩌면 개발적 감각은 없어도 되는 포지션이라 누구에게는 어렵고 누구에겐 좀더 쉽게 느껴질수 있겠다 (개인적으로 경제 학문을 공부한 사람이 유리 할 거 같다 당연한 소리인가...?)

우리 프로젝트에는 JMT, vJMT 토큰이 두가지가 존재하는데 각각 발행되는량이 다르고 초기 공급량이 다르다 그리고 게임 컨텐츠를 통해 추가 발행되는 토큰도 있고 한번에 발행되고 점차 Burn되어 전체 유통량을 줄이기도한다

결과적으로 우리 게임 또는 디파이속에서 How? 에 대한 고민이 토큰 이코노미고 이부분에 Why? 근거가 바탕이 되어야하는 부분이다, 예를 들어 토큰 인플레이션 방지를 위해 전체 발행량에서 매주 2% Lock Up이 해제된다거나 등 이부분을 코드로 옮기고 개념화시키면 이것이 토큰 이코노미다

# 내가 설계한 토큰 이코노미

토큰 이코노미1

우리 프로젝트는 블록체인위에서 개발되었지만 P2E라는 타이틀을 최대한 벗어나고자 노력했다 그결과 게임성을 위해 좀더 기획적인 부분을 컨텐츠로 보안하고 수집욕구를 느낄수있게 게임을 구성하였고 그래서 전반적인 그림을 보면 "블록체인이 들어간 WEB3 게임" 정도로 인식할수있는 수준을 만들게 되었다

Game 과 Defi를 나누었고 Defi와 블록체인을 몰라도 게임을 플레이하는데 전혀 지장이 없게 설계를 하여

최종적으로 Game 시스템과 디파이를 최대한 분리시켜놓고 디파이의 영역이 게임에 큰 영향이 끼치지않는선에 디파이를 구성하였다

토큰 이코노미2

우리가 생각한 그림이 2번 그림의 캐릭터의 위치다

어떻게 보면 캐릭터가 양쪽 모두 상호작용을 무조건 해야지만 게임을 즐길수있는것 처럼 보이지만

좀더 넓게 보면 캐릭터는 어느한쪽만 선택해도 전혀 문제가 없다는걸 보여주고 싶기도 하다

디파이만 해도 문제가 없으면 게임만 해도 문제가 전혀 없다

# 폴리곤 네트워크를 갑자기 선택한 이유는?

폴리곤은 처음부터 고려되지않았다.

하지만 개발을 지속적으로 해오면서 우리팀은 항상 고민이 있었다 그것은 "속도" !!

속도의 문제는 심각 했는데 유저 인터랙션 대부분이 블록체인 지갑을 불러와서 소통을 하고 동기적으로 동작하기 때문에 속도에 불편한 우리나라 사람은 아마 게임을 하다 답답해서 그만두시는분도 계실거라 생각이든다.

게임 속 7할이상의 컨텐츠는 반드시 컨트랙트콜로 구성되어있기에 개발을 하던중에서도 테스트하는 과정이 답답하게 느껴졌다.

이러한 문제를 항상 하던 우리는 프로젝트를 진행중 사이드체인에 대한 언급을 계기로 각자의 팀원들은 사이드체인에 대해 각자공부를 하고 자료를 수집하여 서로 공유하였고 현재 상황에서 기존을 유지한상태에서 가장 빠르게 확장할수있는 레이어2 솔루션인 폴리곤으로 선택 하게 되었다

# 프로젝트를 진행하면서 어려웠던 점은?

담당 업무로는 자동화된 마켓 메이커(CPMM)을 구현하는것이였다, 그리고 아래 항목이랑 조금 중복이 되는데

컨트렉트 코드는 디버깅 또한 비교적 쉽지않아 복잡함이 추가될수록 난이도가 상승하는걸 느꼈다.

오라클 문제는 게임에서 가장 중요시되는 문제였다 랜덤성이라는게 반드시 존재해야했는데 온체인에서 해결할수있는 방법이 거의 전무했다 기한은 한정적이고 많은양은 살펴 볼수없었던 우리는 첫번째 대안으로 keccak256 함수로 난수 문제를 해결하려 했다. 하지만 해당 함수는 보안성이 중요한 블록체인에서 예측가능한 영역이 존재하기에 안전하다 할 수 없었다

이어서 체인링크나 다른 플랫폼을 사용하여 해당 문제를 해결하려 했지만 시간 관계상 해당 문제는 이후 해결할 과제로 남게되었다.

지금 프로젝트가 끝난후에도 랜덤성을 해결할수있는 방법이 무엇인지 조사해 보았는데 괜찮은 아이디어가 떠올라서 다음 블로그에 포스팅 해볼려고한다.

# 컨트랙트는 생각보다 어렵다

코딩을 안해본 사람, 개발을 안해본사람이 컨트랙트 코드를 짠다면 어떤 느낌인지 모르겠지만 상대적으로 컨트랙트 코드를 작성하는건 기존 프로그래밍에 비해 어렵다, 이게 컨트랙트 코드는 한번 작성하면 라이브에서 수정하기가 굉장히 힘들다 그래서 예외 처리를 위한 Require문 작성 사전 처리 Modifier 작성등 최대한 가능한 모든 시나리오를 생각하여 작성해야한다 그리고 라이브 배포하는것 또한 가스비문제 떄문에 기존 개발처럼 코드를 수정하고 배포하고를 반복할수없다

가장큰 이유는 "Gas" 떄문인데 수수료가 EVM 보다 저렴한 Polygon 이라면 좀 덜한데 우리 프로젝트에서 ETH 에서 한번 배포할때마다 2.5 ETH를 가스비로 지불했었다 이게 실제 Main Net 배포 였다면 한번에 500만원씩 수수료로 지불한다는거다 그래서 항상 컨트랙트 작성할떄는 Local -> TestNet -> Live 순서를 반드시 지켜주면서 시나리오 테스트를 충분히 오랜기간동안 잘 거쳐야함을 느꼈다

결과적으로 어렵다는 표현이 신중해야 한다로 포장이 될수있는거같다 그만큼 집중해야하고 최소한 EVM 기반에서 개발되는 컨트랙트는 코드의 최적화에 포커싱을 맞춰야함을 느꼈다

# 결과적으로 난 너무 좋았다

아쉽지만 좋은건 사실이다

좀더 구현하고 고려하고 싶었던 기능들도 많았지만 시간이라는 자원은 한정적이기에 우리는 후회하지않을만큼 포기하지않고 프로젝트를 우리가 그리고 싶은 그림만큼 그릴수있었다. 기술적으로 예외처리, 여러 시나리오를 세우고 테스트를 거쳐 시스템 문제점도 파악을 더 했어야했지만 팀 원들이 밤낮 안가리고 노력한 모습을 보면 후회는 없다.

개인적으로 나한테는 큰 성장을 가져왔다. 팀 프로젝트를 제대로 해본경험이 없던 나에게 있어서 너무 소중한 경험이였고

왜 협업이 중요한지 크게 깨닫는 순간이였다.

역시 혼자 보단 둘 이상이 더 다양하고 창의적이다. 그 이유는 커뮤니케이션의 중요성 ..!

project video : https://youtu.be/5RCWVM8WV0o

[Team Project] 회고록

devbi — Thu, 1 Sep 2022 02:49:12 +0900

목표 : SNS IC 커뮤니티 개발

팀원 : 4명

기한 : 2주

사용 스택 : React, MongoDB, nodejs, solidity(eth)

담당 파트 : 프론트, 백앤드

이전 회사에서 풀스택으로 근무 했을때 팀 으로 프로젝트를진행한다는 느낌을 받은적이없었다

이번 기회를 통해서 팀프로젝트을 경험해 본다

먼저 Git을 활용한 프로젝트 관리를 통해 기능을 나누어 구현을 하고 합병하고 커뮤니케이션하며 하나씩 하나의 목표를 위해 함께한다는는게 즐겁다는것을 느꼈으며 혼자했을때의 답답함을 벗어던지고 대화를 통해 다양한 해결 방법이 도출될수있다는것을 느끼며 팀에 대한 메리트를 느끼게 되었다

다들 팀워크가 서툴어서 의사소통의 문제와 제대로된 업무 분담이 힘들어 겹쳐진 부분도있어 합병에 충돌이 나는 문제를 겪는 조금의 문제가 있었지만 해결을 하였고 다음에 진행하게될 프로젝트에서 이와같은 실수를 반복하지않게 상호간에 프로토콜을 만들어 진행해야하는 필요하다는 생각이든다

프로젝트의 진행은 처음엔 순탄하였다

내가 맡은 파트는 프론트와 백앤드였다

프론트에서 React 기술을 활용한 프로젝트는 처음이기에 필요한 기술들을 학습하여 적용하는것이 필요했다

프로젝트 초창기에는 다들 욕심이 있어서 기존에 있던 기획에서 간단한 커뮤니티가아닌 SNS를 적용하게 되어 작업량이 늘어났기에 더욱더 속도를 붙일 필요가있었다

먼저 백앤드 환경설정과 디비셋업을 먼저 한후 프론트 작업을 진행하였다

역시 처음 부터 만드는것을 기한내에 끝내지 못한다고 판단하여 UI배치구도와 기능설명과 work flow만 간단하게 작성한후 팀원들과 얘기를 통해 수정 보완을 한후 UI 템플릿을 찾았다 html코드로만 짜여진 템플릿이였고 react에 적용하여 컴포넌트 분리를 시키는 작업을 시작하였고 MaterialUI를 사용하여 ui의 부족한 요소를 채워 넣었다

순탄하던 프론트 작업은 상태관리에서 문제가 생겼다

모든 어플리케이션은 생명주기를 가지고있는데 페이지에 필요한 상태값에 대한 동기화가 전혀되지 않아 지갑주소 또는 로그인시 유저정보등을 활용한 post렌더링과 api호출이 되지않아 시간이 지체되었다

문제점은 렌더링전 비동기호출에대한 데이터를 바인딩하고 자식 컴포넌트가 해당 상태값을 가지고 렌더링을 해야했는데

useEffect()사용한 방식으로는 렌더링이후의 작업 밖에 구현이 되지않았 제대로된 렌더링이 보여지지 못했다

찾아보니 componentWillMount 수명 주기 방법이 있었는데 해당 방법은 17v 까지만 지원을 하여 이후 부턴 deprecates 되어

액세스가 불가하여 다른 방법을 찾았으며

그방법은 간단하였다

자식 컴포넌트에 넘겨주기전 user != ?? 상태값을 체크한후 다시 렌더링 시키는 방법으로 해결하였다

이부분을 제외하고서는 프론트 작업에서 문제는 없었다

짧은 시간이었지만 react대한 숙련도가 많이 올라갔으며 왠만한 어플리케이션은 구현가능한 수준까지 끌어올려 뿌듯하였다

이후 백앤드인데

프론트 작업을 하면서 중간 중간 백앤드 작업도 같이 진행하였다

팀 미팅을 통해 필요한 api를 요청하였고 팀원이 다른 작업중이라 일부분의 API를 직접 추가하여 구현하여 적용했다

백앤드에서 문제는 크게없었다

프로젝트 막바지쯤 SNS 형태의 IC 커뮤니티에 문제점이 생겼다

Contract를 호출하는도중 tx가 생기면 기본적으로 서명이 필요하다 tx가없는 storage에 저장된 데이터를조회 하는건 문제가 되지않았다

기본적으로 우리는 계약에 대한 서명이라는것은 본인이 직접 서명을 해야하지않겠냐라는 의견에 동의하여 클라이언트 - Contract의 인터랙션을 기본으로 생각하여 작업을 진행했었다

하지만 사용자가 게시물을 작성하고 댓글을 달고 좋아요의 액션을 취할시 Market Contract로 부터 토큰을 분배 받는데

매번 서명 창이 떠야하는 문제가 생겨 서비스질이 낮아지는 현상이 생긴거다

이부분은 굉장히 크리티컬하여 백앤드 구조를 바꿔야하는 상황이 생겼다

백앤드에서 지갑을 생성하고 컨트랙트 서명을 한후 토큰을 전달받는식으로 진행이 필요했던것이다

이부분에 아쉽다고 느낀것은 조금만더 구현이후 발생했을 시나리오를 조금만 떠올려봤다면 이러한 불편함과 문제점을 찾을수 있을것이라고 생각이든다

기본적으로 이번 프로젝트에 필요한 최소 기능이상의 구현을 하여 다행이라 생각이들지만

아쉬움을 지울수가없었다

다음번엔 좀더 디테일하게 접근할 필요하다

프로젝트 소개 : SNS 기반의 IC 커뮤니티

- 기능 :

게시물 업로드,

댓글,

팔로우,

구글 로그인,

로컬 로그인,

NFT생성 구매 거래,

ERC20 토큰 거래

메인 페이지- 게시글 업로드, 댓글, 팔로우 수행

마이 페이지 - 유저 정보 조회, 토큰 전송, 게시물 관리

NFT 마켓 - NFT 구매 (마켓 전용 토큰 사용)

프루닝

devbi — Wed, 31 Aug 2022 00:51:41 +0900

프로젝트도 끝나고 휴식으로 충전도좀 하고!!

다시 기본적인 블록체인의 이론에대해 정리 해보는 시간을 가져보자

프루닝(Pruning)?

경량화 기법으로, 인공 지능 분야에서 검색 모델을 학습한후에 불필요하거나 중요도가 낮은 노드 등을 제거하는 기술

이게 무슨말이냐면

중요한건만 냅두고 불필요한건 삭제하자 이런말이다

블록체인에서는 오래된 블록체인 데이터를 자동으로 삭제하는데 사용이된다

대표적으로 비트코인과 이더리움에 대해 알아보자

- 비트코인

비트코인 노드는 블록체인의 사본을 보관하고 네트워크를 실행하는데 필요한 여러 태스크를 수행 하는데

많은 스토리지를 낭비하는 문제가 있다

많은 스토리지?

비트코인은 300GB 이상을 차지하는 블록체인 DB가 있는데 2009년부터 지금까지 해당 네트워크가 중단된적이 없기떄문에 엄청난 데이터가 저장 되어 있다

비트코인의 문제점 : "블록체인 크기의 가속화된 성장"

이문제를 해결하기위해 비트코인팀은 Block file pruning이라는 bitconin core 0.11.0 version에 추가

해당 기능을 탑재하면 다음과 같은 이점을 얻을수있습니다

Block pruning을 통해 작은 버전의 '풀 블록체인'을 실행 가능
참조할 가능성이 없는 불필요한 정보를 삭제 10GB 미만으로 추정
prune mode 에서는 지갑을 실행하면 이전 트랜잭션과 오래된 체인 기록이 삭제되어 디스크 공간을 절약

비트코인 네트워크는 모든 트랜잭션을 가지고있기에 오래된것부터 최신 것까지 전부 가지고있습니다

하지만 블록을 실행하고 검증하는 데 중요한 것 은 블록 내 트랜잭션 내의 인/아웃풋의 사용 가능 여부 인데

굳이 모든 트랜잭션을 저장하지않아도 된다

지금은 풀 블록체인을 다운로드하여 올바른지 확인하고 필요한 '최신 정보'만 복사한뒤 나머지는 버리게 됩니다.

저장한 블록체인은 풀 블록체인의 자식 트리(머클트리)이며, 원본 블록체인의 부분 복사본입니다.

- 이더리움

이더리움에서는 프루닝을 State Trie Pruning 라고 합니다

이게 뭐냐면 현재 상태를 Prefix tree 일종인 Modified Merkle Patricia Trie(MPT,상태전이 머클 확장 페트리샤 트리..) 로 저장을 합니다

여기서 이더리움 상태는 Account 상태인데 key-value 구조로 저장합니다

사용자가 늘어나면 당연 이더리움 어카운트가 계속 늘어나고 늘어나면 버거워지고 느려졌습니다

이를 해소하기위해 이더리움이 추가 보안한 머클트리가 MPT

MPT는 State Root의 Hash를 계산하기 위해 전체를 볼 필요가없습니다 수정된 브랜치의 Hash만 다시 계산하조

그래서 root Hash를 빠르게 찾을수가있습니다

State Trie Pruning

MPT는 새로 삽입되는 노드의 수를 최소화 하는데

위 그림에서 Block N과 Block N+1 차이는 A의 오른쪽 자식값이 10 에서 20으로 변경된거 밖에없조?

이렇게 되면 변경된 값말고는 나머지는 그대로 사용이 가능하다는 말입니다

그래서 MPT는 푸른색으로 그려진 3개의 노드만 새로 추가해서 위 그림처럼 구성하게 됩니다

그러면 갱신된 Block N+1은 붉은색이제 필요없으니 지워도 되겠조?

프루닝은 불필요한걸 제거하는 기술이니깐요

하지만 지울수가 없다네요..ㅜㅜ

그이유는 이더리움은 블록의 Finality를 보장 하지 않아서 입니다

다른 말로는 Block N + 1 이 Block N으로 다시 Retract 될수도 있고 web3.js API 통해서 과거의 State에 접근하는것도 가능해야하기 떄문이조 그래서 현재 상태에서 안 쓰이는 노드를 바로 지울수는없습니다 ..

그렇다고 영원히 남겨둘수도없조... 현재 최신 State 크기의 이더리움은 약 25GB인데 과거 State 전부 저장하면 300GB 넘어갑니다 게다가 이 크기는 참여자가 많을수록 점점 늘어나겠조 그래서 현실적으로 전부 저장하는것 또한 힘듭니다

결과적으로 이더리움은 과거의 State를 127개로 제한했고 그보다 오래된 State는 지울수있게 했습니다

하지만 DB에 저장되어있는 과거 데이터를 찾아 지우는것도.. 쉬운건 아니조 ..

이더리움 프루닝의 문제

앞서 말한 이유로 이더리움은 프루닝을 쉽게 사용하기가 어렵습니다

그래서 제한적으로 적용하고있는데 Go-Ethereum 에서는 매우 한정적으로 STP하는데

State Trie에 대해 캐시를 사용하고 이 캐시에만 저장된 노드에 대해서는 Pruning을 하고 DB에 저장된 노드는 Pruning을 하지 않는 방식입니다. 캐싱된 노드는 서버가 정상적으로 종료되거나, 생성된 지 128Block이 지났거나, 캐시 크기를 넘겼거나, 마지막으로 캐시된 노드가 DB에 저장된 지 5분이 지나면 DB에저장됩니다 즉 위 조건을 만족하기 전에는 Cache에서 삭제된 노드는 DB에 저장하지 않습니다.

그런데 생성된 지 5분이 지나지 않아서 삭제되는 노드는 그리 많지 않습니다. 따라서 대부분의 삭제됐어야 할 노드는 여전히 DB에 남아 있습니다. 이에 대해 이더리움에서는 State Pruning을 구현하는 것을 계속 시도하는데 STP가 실제로 구현 되기전에는 Fast Sync를 사용을 권장하고 있습니다.

다음은 세 과정을 거치면, 새 노드에서는 Fast Sync로 동기화된 상태까지의 Garbage Node 없이 유효한 노드만 관리할 수 있습니다.

1. 새 클라이언트를 생성

2. 기존 클라이언트에서 새 클라이언트로 Fast Sync를 받는다

3. 기존 클라이언트를 제거한다.

이렇게 보면 되게 좀? 이런 생각이 드는데 위험 부담이 있는 Garbage Collection을 구현하는 것보다는 안전하고 현실적인 해결책이라는걸 알아야합니다

결과적으로 이더리움은 Garbage Collection이 구현되기 전까지는 계속 위와 같은 방식을 사용 할 수 밖에 없습니다..ㅠ

IPFS? IPFS 동작 방식

devbi — Wed, 24 Aug 2022 20:42:00 +0900

IPFS(Inter Planetary File System) 으로 Git, BitTorrent, kademlia, Bitcoin 같은 서비스에서 영감을 받아 시작된 오픈 소스 프로젝트

IPFS는

- 분산형 파일 시스템에 데이터를 저장하고 인터넷으로 공유하기 위한 프로토콜

- P2P 네트워크 사용

이러한 특징을 가지고있다

기존 HTTP 프로토콜 방식은 데이터가 위치한 곳의 주소를 찾아가서 요청한 컨텐츠를 가져오는 방식이라면, IPFS는 전 세계 여러 컴퓨터에 분산 저장된 각 데이터 조각으로 잘게 나눠서 가져온 후 하나로 합쳐서 보여주는 방식으로 동작 합니다

IPFS는 프로토콜이면서 파일시스템, 웹, 모듈러, 암호화, p2p, CDN, 네임 서비스등 모든것을 아우르는 말입니다

프로토콜

- Content-addressed 파일 시스템

- 콘텐츠 전달

- Kademlia + BitTorrrent + Git 결합

파일 시스템

- 디렉토리, 파일기반

- 마운트 가능한 파일 시스템 (FUSE를 통한)

웹

- 전통적인 웹과 같이 문서를 보는데 사용가능

- HTTP를 통해 파일에 엑세스 가능

- 브라우저 및 확장 프로그램은 IPFS:// or dweb:/ipfs/의 url, uri 스키마를 직접 사용하는 방법

- Hash-addressed 컨텐츠가 신뢰성을 보장

모듈러

- 모든 네트워크 프로토콜의 연결 계층

- 라우팅 레이어

- DHT(Kademlia/Coral) 라우팅 레이어 사용

- 경로 기반 네이밍 서비스 사용

- BitTorrent에서 차용한 블록 교환 사용

암호화

- 각 컨텐츠에 암호화 해시 주소 지정

- 블록 수준 중복 제거

- 파일 무겴성 및 버전 관리

- 파일 시스템 수준에서 암호화 및 서명 지원

p2p

- 전 세계 p2p 파일 전송

- 완전한 분산 아키텍처

- 중앙 실패 지점 없음!

CDN

- 로컬에서 파일을 추가하면 전 세계에서 사용 가능

- 캐싱 친화적

- BitTorrent 기반의 네트워크 대역폭 분포

네임 서비스

- SFS에서 영감 받은 네임 서비스, IPNS

- PKI(공개키 암호화) 기반 글로벌 네임 스페이스

- 신뢰 사슬 구축

- 다른 NS 서버와 호환

- DNS, .onion, .bit 등을 IPNS에 매핑 가능

IPFS를 사용하게 되면 해당 컴퓨터는 필요한 파일들을 다운받는 것과 동시에 파일을 나누어 주는 역할을 하게 됩니다

IPFS 대표적인 특징은 아래와 같습니다

- 분산화

- 컨텐츠 어드레싱

- 참여

분산화

- IPFS는 중앙 서버가 아닌 분산된 환경의 여러 피어로부터 파일을 다운로드 받을 수 있습니다

안정적인 인터넷 지원 : 중앙 서버는 오류가 생기면 파일 다운로드가 불가능한 기존 구조 대비 IPFS는 동일한 웹 페이지를 얻을 수 있다
컨텐츠 검열이 어렵게 한다 : 파일, 분산된 환경에서 전달된다는 특성으로 인해 위화 같이 특정 정보에 접근 하는것을 막거나 검열하는 것을 어렵게 합니다
웹 속도를 높일 수 있다 : 요청하는 컴퓨터가 멀리 떨어져 있거나 인터넷이 연결되지 않은 상황에서도 주변의 가까운 피어에게 파일을 받아올수 있다

컨텐츠 어드레싱

/ipfs/Qmso1kxJW3WknfiKAnzncl42Vedxjaquocus5asm/doc/index.html

- 컨텐츠 어드레싱이란게 컨텐츠를 주소 기반으로 표현한다는 말입니다

- PFS 컨텐츠는 URL은 위와 같은 형태이다

- /ipfs/ 다음의 문자열을 컨텐츠 식별자 (CID)라고 하는데 이를 통해 여러 피어로부터 컨텐츠를 가져올수있다

https://sool.document.org/doc/index

/kbi/user/document/index.txt

- 위와 같은 전통적인 URL 또는 파일 경로는 해당 위치를 기반으로 파일을 식별하게 됩니다

하지만 IPFS는 파일에 포함된 내용을 기준으로 파일의 주소를 식별 합니다

이게 가능한 이유는 해시는 컨텐츠마다 고유하다는 특성떄문입니다

이러한 이유 떄문에 컨텐츠 내용이 조금이라도 바뀌는 경우에 CID가 바뀌기 때문에 업데이트가 잦은 경우 새로운 링크를 보내는것은 비효율적입니다

하지만 이러한 부분은 IPNS, MFS, DNSLink를 통해서 보완이 가능합니다

IPFS란게 사용해야하며, 참여해야하며, 상호간 협력적이어야한다는게 가장 중요합니다

아무도 CID를 가지고 있지 않으면 해당 컨텐츠는 절대 얻을수없지만

해당 CID를 단 한 사람이라도 가지고 있다며 해당 컨텐츠는 지울수가 없는 특징이 있습니다

참여

IPFS는 기본적으로 사람과 컴퓨터가 통신하는 방식을 바꾸자는 아이디어에서 출발했습니다

web2.0의 소유권과 액세스를 기반으로 구성되어 있어 파일을 소유한 사람이 액세스 권한을 부여 하기로한 경우에만 파일을 받을수있는데

IPFS는 소유와 참여를 기반으로 동작하기에, 많은 사람이 파일을 소유하고 사용 가능하게 만드는데에 초점이 맞춰져있습니다

결과적으로 IPFS 사람들이 적극적으로 참여해야한다는 가정에만 정상적으로 서비스가 동작할것입니다

자 그러면 IPFS 동작 방식에 대해 알아봅시다

IPFS는 P2P 네트워크로써 전 세계어디에나 있는 피어를 통해 액세스 할 수 있습니다

IPFS 동작 방식을 이해 하기 위해서는 3가지 원칙을 알아야 합니다

- 컨텐츠 어드레싱 (CID를 통해 고유 식별)

- DAG를 통한 컨텐츠 연결

- DHT을 통한 컨텐츠 검색

컨텐츠 어드레싱

- IPFS는 파일의 내용을 해시화 하여 CID를 생성 합니다

- 다른 분산 시스템에서도 해시를 통해 컨텐츠 식별뿐 아닌 컨텐츠를 서로 연결하는 수단으로 사용 합니다 (ex. git 커밋, 블록체인 등등)

- 그러나 서로 상호 운용 가능하지 않고 연동 되지 못하기도 하여 이러한 문제를 해결하기 위해 IPLD라는 프로젝트가 진행되고 있습니다

- IPLD는 해시 연결 데이터 구조사리를 변환 하여 분산 시스템 전반에 걸쳐 데이터를 통합할 수 있도록 합니다

DAG(방향성 비순환 그래프)

- IPFS 및 다른 분산 시스템은 DAG 자료구조를 사용하는데

특히 각 노드에는 노드 컨텐츠의 해시가 있는 Merkle DAG를 사용합니다

이는 컨텐츠 어드레싱 개념과 통하는 부분이 있습니다

- IPFS는 디렉터리롸 파일을 나타내는 것에 최적화된 Merkle DAG를 사용하는데, 이떄 다양한 방법으로 Merkle DAG를 구성할 수 있습니다 (Git도 여러 가지 버전을 가진 Merkle DAG를 사용 합니다)

- 컨텐츠를 하나의 Merkle DAG로 만들기 위해서는 먼저 컨텐츠를 블록 단위로 분할해야 합니다

컨텐츠를 블록들로 나누어서 두 개의 유사한 파일이 있는 경우 Merkle DAG의 일부를 공유할 수 있게 되는거조

즉, 다른 Merkle DAG의 일부가 동일한 데이터 하위 집합을 참조 할 수 있게 됩니다

이렇게 되면 매번 완전히 새로운 파일을 만드는 대신 새롭게 변경된 부분만 전송 받을수 있습니다 (BitTorrent 처럼 말이조)

https://github.com/ipld/explore.ipld.io/blob/master/README.md

Merkle DAG에서 모든것에 CID가 있는데

폴더 그자체, 폴더에 있는 파일들, 해당 파일은 블록까지 모두 CID를 가지게 됩니다

정리하면, IPFS는 컨텐츠에 CID를 부여하고 Merkle DAG를 통해 컨텐츠를 연결 합니다

DHT(분산 해시 테이블)

- 어떤 피어가 컨텐츠를 호스팅하고 있는지 탐색할려면 IPFS는 DHT를 사용합니다

- K-V로 구성된 데이터베이스 입니다

- 해당 테이블은 분산 네ㅔ트워크에 참여하는 모든 피어게 나누어져 존재하는 하나의 테이블 입니다

- 결과적으로 컨텐츠 탐색하기 위해서는 이러한 여러 피어들에게 질의를 하게 됩니다

- IPFS는 DHT를 제공하고 서로 연결하고 소통하는 피어를 처리하기 위해 libp2p라는 프로젝트를 제공 합니다

- 컨텐츠가 어디에 있고, 어떤 피어가 컨텐츠를 구성하는 각 블록을 저장하는지만 알게 된다면, DHT를 사용하여 해당 피어의 현재 위치를 알아낼수 있습니다

- 정리하면 컨텐츠 다운로드를 위해서는 두번의 쿼리가 필요합니다

1. 피어의 위치찾기

2. 컨텐츠 내용 찾기

다른 피어에게 블록을 요청하고 블록을 보내는데 사용되는건 Bitswap 이라는 모듈을 사용합니다

Bitswap 사용시 원하는 컨텐츠를 가지고 있는 피어에게 연결하고 원하는 목록을 보내고 요청한 블록을 받을수 있습니다

요청한 블록이 도착하면 컨텐츠를 해시하여 CID를 얻고 이를 요청한 CID와 비교하여 정확한 데이터를 받았는지 검증할 수 있습니다

해시 테이블, DHT

devbi — Tue, 16 Aug 2022 23:05:18 +0900

Hash Table이란 키를 입력값으로 해시함수(hash function)을 사용하여 변환한 해시(hash)값을 색인으로 삼아 키와 데이터를 저장하는 자료 구조 입니다

해시함수를 사용하여 변환한 해시를 색인으로 삼는 Key-value 구조

hash table에서 저장, 삭제 검색 과정 모두 평균적으로 O(1)의 시간복잡도를 가지고 있어 데이터를 다루다 작업이 빠르다

다만, 해시 충돌이 발생할 수 있고 데이터가 저장되기 전에 저장공간을 미리 만들어놔야 해서 공간 효율성을 떨어진다

해시 함수가 복잡해지면 해시값을 만들어내는데 많은 시간이 소요되 해시 함수가 중요

Hash Table 구조

- Key : 다양한 길이의 값이 들어올 수 있음, 해시 함수를 통해 변환하지 않은 상태로 저장소에 저장이 되면 다양한 길이만큼의 저장소를 구성해 두어야함

- Hash Fuction : Key를 hash로 바꿔주는 역할을 함, 서로 다른 키지만 같은 해시가 되는 해시 충돌 위험이 있음

- Hash : 해시 함수를 사용하여 만들어진 결과물, 저장소에 데이터와 매칭되어 저장

- data : 저장소에 최종적으로 저장되는 값으로 색인(index)와 매칭되어 저장

대표적인 해시 알고리즘

- Division Method :

Number type의 키(key)를 저장소의 크기로 나누어 나온 나머지를 색인으로 사용하는 방법

저장소의 크기를 소수로 정하고 2의 제곱수와 먼 값을 사용하는 것이 효과가 좋음

예를 들어, Key값이 23일때 테이블의 크기가7이면 index는 2

- Digit Folding

키(key)의 문자열을 아스키코드로 바꾸고 그 값을 합해 저장소에서 색인으로 사용하는 방법

- Multiplication Method

숫자로된 Key 값 K와 0~1 사이의 실수 A, 보통 2의 제곱수인 M을 사용하여 다음과 같이 계산

index = (KA mod 1)m

- Universal Hashing

다수의 해시 함수를 만들어 특정한 장소에 넣어두고, 무작위로 해시함수를 선택해 해시 값을 만드는 방법

해시 충돌 해결 방안

개방 연결법

Linear Probing
Quadratic Probing
Double Hashing Probing

분리 연결법

DHT(Distributed Hash Table)

- DHT는 해시 테이블을 활용해, K-V 쌍 방식으로 데이터를 검색하는 분산형 데이터베이스

- DHT는 P2P 환경에서 데이터를 분산하여 저장할때 사용

DHT 저장 방식

1. 해시 테이블범위가 0~7 까지

2. 이 테이블을 4명의 호스트가 사용됩니다 , 호스트들은 각각 공유할 데이터를 가지고 있음

3. 각 해시테이블의 인덱스에 호스트 IP주소를 삽입, 정해진 해시 테이블의 인덱스 안에 호스트의 주소를 할당하기 위해 호스트의 IP주소를 해싱 해싱한 결과값을 8로 나눈 나머지 값을 인덱스로 한다

4. 이후 호스트들은 자신 다음에 있는 호스트 중 가장 가까이에 있는 호스트의 IP주소를 알게 됨

5. 해시 테이블에 인덱스에 호스트의 IP주소 외에도, 데이터의 위치를 저장

각 호스트는 공유해야 하는 파일을 가지고 있음

이 파일들 역시 IP주소를 해싱하여 인덱싱한거 처럼 동일한 방식으로 해싱

이렇게 나온 해시값을 그대로 해시테이블에 인덱싱

'기획서.HWP'의 해시 값은 5이므로, 해시 테이블의 인덱스5에 있는 호스트인 789.0.5.4는 기획서가 123.0.20.8에 있는것을 기억하게 되는 겁니다!

DHT 데이터 검색 방식

458.0.13.2 컴퓨터가 카카오톡.exe를 찾는다고 가정

1.456.0.13.2는 자신의 가장 가까운 컴퓨터인 123.0.20.8에게 요청

2. 456.0.13.2는 자신의 가장 가까운 컴퓨터인 123.0.20.8 에게 요청

3. 123.0.20.8 은 가계부.csv 위치는 알지만 카카오톡 위치 주소는 모르기 때문에 자신의 가장 가까운 컴퓨터인 789.0.20.8에게 카카오톡 위치를 물어본다

4. 789.0.20.8 또한 모르기 떄문에 위와 같이 가까운 컴퓨터에게 요청

5. 101.0.234.5 는 카카오톡.exe 위치를 알기에 처음 요청했던 456.0.13.2에게 카카오톡 위치를 알려줌

블룸 필터(Bloom Filter)

devbi — Sun, 7 Aug 2022 16:54:14 +0900

블록체인 기술 블룸 필터에 대해 알아봅시다

블룸 필터란 특정 원소가 집합에 속하는지 검사하는데 사용할 수 있는 확률형 자료 구조 입니다

확률적 검색 필터로 원하는 패턴이 무엇인지 정확하게 규정할 필요 없이 원하는 패턴을 설명하는 방식이라, 통계적 특성을 보였다고 할수 있습니다

또한 많은 양의 데이터를 줄여서 공간 효율적으로 빠르게 검색이 가능합니다

블룸필터는 프라이버시를 보호하면서 검색 패턴을 구현하기 위한 효율적인방법을 제공합니다

또한 블룸필터는 비트코인 언리미티드팀이 노드에 알려지지 않은 거래를 식별하는데 도움을 주고 있습니다

예로 SPV노드가 블룸필터를 사용해 이웃 노드들에게 특정 거래를 제공해 달라고 요청하는데 이때 노드는 검색중인 주소가 정확히 어떤 주소인지 밝힐 필요는 없습니다

자세히 알아봅시다

먼저 블룸 필터가 어떻게 동작 하는지 알아봅시다

블랙 리스트 기반 IP주소 검색및 차단의 예를 들어 설명하겠습니다

1. x,y,z 라고 하는 IP를 블랙리스트에 저장

2. 방화벽에 이러한 블랙리스트의 IP를 차단하려고 등록한다고 가정

블룸 필터는 N비트 크기의 비트 배열구조와, 서로 다른 J가지의 Hash함수를 사용하여 구현 합니다

해시함수는 N가지의 값을 균일하게 출력해야합니다!

블랙 리스트에 어떻게 IP주소가 저장되고 패킷이 들어올떄 어떻게 블랙 리스트와 IP주소를 비교를 하는지 살펴봅시다

블랙 리스트에 IP 주소 저장 순서

1. 블랙리스트로 로그에 X의 IP를 저장

2. IP x를 가져와 3개의 해싱 함수(f1,f2,f3)로 해싱

3. 각 해싱값에 해당되는 해당 배열 인덱스 값을 1로 수정

18(N)개의 비트 배열, 그리고 3(J)개의 해싱 함수 사용

4. IP y로 1~3번 과정을 반복

5. IP z로 1~3번 과정을 반복 (이전 인덱스 값이 0이 아닌 1인경우 수정없이 1로 유지)

여기 까지가 블랙리스트로 저장하는 방법입니다

이후 IP주소가 들어왔을때 필터링 하는 과정을 살펴 봅시다

1. w 라는 IP를 가진 패킷을 받음

2. IP w를 위의 방식과 같이 3개의 해싱 함수(f1,f2,f3)로 해싱

3. 4,13 인덱스 값은 1이지만 15의 인덱스 값은 0 이므로 w라는 IP는 블랙 리스트 IP가 아님

마지막 3번을 보면 3가지의 인덱스중 2개만 1이기 떄문에 블랙리스트로 등록된 IP로 판별하지않습니다

반대로 3가지 인덱스가 모두 1이라면 블랙리스트로 등록된 IP로 판별합니다

블룸 필터의 특징

1. N의 이진 배열 1부터 ~ N까지 출력값을 갖는 J개의 해시함수를 가지는데 N,J를 조절함으로 정확도와 프라이버시 보호수준을 조절 가능

2. 오탐지율 존재, 결정적 결과 대신 부정확한 결과를 얻을 수 있음

3. False Negative(존재하는데 부정하는것)는 존재하지 않는다고 보장할 수 있다

4. False Positive(거짓-긍정, 존재 하지않는데 있다고 하는것) 존재함

위 예에 따라 정상IP를 블랙리스트로 판단할 가능성이있다

블룸 필터 사용예

1. IP주소 검색및 차단 필터링

2. 문자열 맞춤법 교정

3. 가상화폐

4. 라우터

5. 크롬 브라우저

6. 빅데이터 환경

Tap root(탭루트)

devbi — Sat, 6 Aug 2022 12:51:19 +0900

비트코인 기술에 대해 알아보자

탭루트(Tap root)는 슈노르 서명(Schnorr Signature)과 함께 세그윗 도입 이후 많은 기대를 모으로 있는 비트코인의 기술적 업그레이드

특징 :

- 프라이버시, 확장성, 보안을 강화 하기 위해 비트코인 스크립트 작동 방식의 변화

탭루트는 비트코인의 프라이버시, 확장성, 보안을 해결하기 위해 사용된다

그렇다면 탭루트란 무엇인가?

탭루트

탭루트는 비크토인의 스크립트를 개선하여 프라이버시를 향상시키고 복잡한 트랜잭션과 관련된 요소를 개선하기 위한 소프트 포크

비트코인의 트랜잭션은 타임락 릴리즈, 다중 서명 조건 등을 포함하여 트랜잭션을 더 복잡하게 만드는 다양한 기능들을 사용할 수 있다

탭루트가 없었을 때는 누구나 다중 서명을 포함한 모든 비트코인의 트랜잭션 이동 과정을 살펴볼 수 있었는데, 이는 모든 사람이 볼 수 있기 떄문에 프라이버시에 좋지 않다

탭루트 업그레이드를 진행하면서 프라이버싯가 개선되었고 트랜잭션에 여러 기능이 포함되더라도 탭루트로 인해 단일한 하나의 트랜잭션 처럼 보이게 되며 보내는 주소와 받는 주소만 확인할 수 있게 되었다

슈노르 서명

탭루트는 슈노르서명 업그레이드로 탭루트가 구현이 가능해졌는데

슈노르는 독일의 수학자이자 암호학자인 클라우스 슈노르(Claus Schnorr)가 개발한 암호학적 서명 체계로 구성되어 있다

기존 비트코인의 창시자 사토시 니카모토가 채택한 서명 체계는 타원 곡선 디지털 알고리즘(ECDSA)었다면, 당시 슈노르 서명 대신 이를 선택한 이류는 이미 널리 사용되었고, 잘 알려져있으며 안전하고 탄탄한 오픈 소스 였기 떄문이다

ECDSA는 각 트랜잭션 마다 디지털 서명하기 떄문에 트랜젹션 사이즈가 커질수있고, 사이즈가 커지기 떄문에 블록체인에 트랜잭션을 넣을 수 있는 양이 많지가 않다

이를 보완하는 슈노르 디지털 서명 체계 적용은 비트코인및 다른 블록체인 네트워크 서명의 새로운 출발점이 될수있었다

슈노르 서명 특징

- 복잡한 비트코인 트랜잭션 내에 다수의 키를 포함할 수 있다

- 단일하고 고유한 서명을 생성할 수 있다

즉, 트랜잭션에 포함된 다수의 주체가 진행한 서명이 단일한 슈노르 서명으로 통합 된다 다른 말로 서명 통합(Signature aggreagation) 이라고 한다

탭루트가 비트코인에 주는 영향

- 블록체인상에서 전송 및 저장해야하는 데이터양 감소

- 블록당 더 많은 트랜잭션 처리 (High Tps ratio)

- 더 저렴한 트랜잭션 수수료

탭루트의 또다른 장점은 서명을 더 이상 변경할 수 없다는것이다

서명을 변경할 수 있다는 것은 비트코인 네트워크에 존재하는 보안 위협중 하나인 "서명 가변성"이라고 하여 트랜잭션이 승인되기 전에 서명을 변경할 수 있다는 것 이다

그 결과 비트코인은 이중 지불 문제에 노출되었고 그 결과 분산화된 원장의 무결성을 훼손할 수 있습니다

탭루트는 이러한 문제를 해결해주는 많은 지지와 기대를 받은 업그레이드 입니다

합의 알고리즘 정리

devbi — Tue, 2 Aug 2022 19:23:38 +0900

합의 알고리즘의 공통적으로 고려되는 항목

1. Finality Problem

2. 51% Attack and BFT

3. Transaction Cost

체인 공개 유형	합의 방식	설명	장점	단점	사용 코인
퍼블릭	POW	각 노드의 연산 능력을 증명하여 블록 생성 높은 컴퓨팅 파워를 가진 노드가 블록을 생성할 확률이 높음, 오랫동안 사용되며 안전성이 검증, 단점도 많음	오랜기간동안 검증	51% Attack 완결성문제 느린 트랜잭션 에너지 낭비	비트 코인
	POS	소유 지분 양에 비례하여 블록 생성 권한을 높은 확률로 부여 받음 많은 지분을 가진 노드가 블록을 생성할 확률이 높으며 이론적으로 우수하지만 실제 대규모 환경에서 검증 사례가 부족하다	51%Attack내성 빠른 트랜잭션 에너지 낭비 적음	완결성 문제 검증 부족	퀸텀 네오 스트라디스
	DPos	일부 위임된 Validator끼리 Pos 수행 트랜잭션 속도가 더 빠름 신뢰도는 Validator의 신뢰도에 종속	빠른 트랜잭션 에너지 낭비 적음	완결성 문제 검증 부족 탈중앙성 부족 보안 취약	EOS
	PoET	경쟁적 연산으로 낭비되는 에너지를 줄이면서 POW 와 유사 효과 하이퍼레저 Sawtooth Lake에서 제안 인텔 SGX를 기반으로 블록을 생성하는 리더를 랜덤으로 선정	검증된 방법의 개선 에너지 낭비 적음	특정 HW 종속	Sawtooth
프라이빗 컨소시엄	PBFT	참가자 1명이 프라이머리가 되어 모든 참가자에게 요청 송신 그 요청에 대한 결과를 집계한 뒤 다수의 값을 사용해 블록을 확정 각 노드는 브로드캐스팅된 명령을 받게 되면 모든 노드에 회신 각 노드는 명령을 일정 수 이상 수신하면 명령을 실행하고 블록을 등록함	완결성 문제 해결 빠른 트랜잭션	참여자 사전 파악 참가자 증가시 성능 하락	패브릭
	PoA	트랜잭션 및 블록의 Validator라고 승인된 계정에 의해 유효성이 검사 Validator의 권리를 얻으므로 그들이 얻은 지위를 유지하고자 함 자신의 신원에 부정적 평판이 생기길 원치 않도록 노력할 거라 가정
	PAXOS
	RAFT	리더를 선정한 후 시스템의 모든 변화는 리더를 통해 결정 신뢰된 네트워크에서만 사용		리더의 조작 가능 BFT 보장하지 않음
	Slieve	IBM에서 고안한 PBFT 확장 알고리즘 실행 결과 전송 과 집계 결과 전송으로 흐름이 나뉨