느려지는 원인 분석 => 컴포넌트가 리렌더링 될 때

1. 자신이 전달받은 props가 변경될 때
2. 자신의 state가 바뀔 때
3. 부모 컴포넌트가 리렌더링될 때
4. forceUpdate 함수가 실행될 때

-> '할 일 1'만 체크했는데 나머지도 다 렌더링되어 비효율이 발생. (379.7ms 소요)

React. memo를 사용해 컴포넌트의 props가 바뀌지 않았다면, 리렌더링하지 않도록 설정함. 그러나 이것만으로 충분하지 않음. todos 배열이 업데이트되면 최신 상태의 todos를 참조하는 onRemove와 onToggle 함수도 새롭게 바뀌기 때문에 배열이 바뀔 때마다 함수가 새로 만들어 짐.

하루가 다르게 풀 수 있는 문제 수가 줄어들고 있다. 문제가 더 어려워진 것도 있지만, 문제에 오롯이 집중하기 어려운 환경도 있는 듯 하다. 매일 매일 문제를 풀면서 개발과 아주 조금은 친해지고는 있지만, 좀 더 적극적으로, 진지하게 공부를 시작해야한다.

오늘은 8개밖에 못 풀었습니다.

오늘도 잊지 않고 문제 풀었습니다. 100개 풀기를 목표로 하니 열의가 생겨서 좋습니다. 알고리즘은 여전히 재미있습니다. 아마도 잘 풀려서인 것 같아요. 레벨이 올라갈수록 더 재밌어지겠죠.

오늘은 시간도 적고, 어제보다 어려울 줄 알고 목표를 10개로 잡았는데, 생각보다 잘 풀려서 15개 풀었습니다. 아마 점점 푸는 문제가 줄어들겠죠? 3일 동안 55문제 풀었는데, 나머지 45문제는 과연 얼마나 걸릴까요?

조만간 리액트 공부도 시작하려고 합니다. 공부했던 거 마저 해야죠^^

어제에 이어 레벨 0 문제 20개를 풀었다. (왜 저기에 레벨 1이라고 되어있지;;) 마지막 4개가 풀기가 어려웠는데 어떻게든 20개 맞추려고 하다 보니까 20개를 풀게 되더라.

알고리즘 문제 풀면서 함수들을 활용하기 위해 자바스크립트 공식 문서를 계속 봤다. 오랜만에 함수들을 보니 반가웠다. slice, map, filter, reduce, pow 등등.. 진짜 자주 썼던 애들인데 이렇게 다시 보는구나! 반갑다 얘들아!!

레벨0라고 얕봤는데 얕보면 안 된다. 지금 풀고 있는 쉬운 문제들은 문제를 푸는 게 중요한 게 아니라 더 심플하게 푸는 게 관건인 것 같다. 풀고 나서 다른 사람 풀이 볼 때, 내가 전혀 생각치 못한 접근일 때 배워가는 게 많다..

내일도 문제 풀고 인증하러 오겠습니다. 저기 저 성장 여정 수치가 매일 매일 바뀌는 재미가 있을 것 같다. 특히 랭킹!! 다 조져버려야지

하지만 막상 다시 시작하려고 하니 무엇부터 시작해야 할 지 막막하더라고요. 부트캠프를 다시 들을 수 있는 것도 아니고, 이제 저 혼자 스스로 찐 자기주도학습을 해야 합니다. 어떤 포지션을 할지, 어떤 언어를 배워야 할 지도 사실 잘 모르겠습니다. 그럼에도 '어떤 프로그램을 만들고 싶다.'는 생각은 있습니다. 그것을 장작 삼아 뭐든 시작해보려고 합니다.

이곳 저의 velog에 작년에 치열하게 알고리즘을 풀었던 흔적이 있는데요, 그 감부터 다시 찾고 싶어요. 그래서 프로그래머스에 가입을 했습니다.

우선 언어도 상기시킬 겸 Level 0부터 시작하려고 합니다. Level 0가 총 100문제이니, 100문제 먼저 푸는 것을 목표로 하려고 합니다. 오늘만 20문제를 풀었는데, 앞으로 더 어려워질테니 하루에 20개씩은 못 풀겠죠? 그래도 해보겠습니다.

개발아! 다시 친해지자!!!

다행히 어느 정도의 여유는 있었다. 프로젝트1은 2명의 인원으로 4일동안 모든 기능을 구현해야 했고, 이번 프로젝트2는 요구하는 과제의 퀄리티는 더 높지만 4명의 인원으로 11일이 주어졌기 때문이다.

프로젝트 주제

💡 블로깅 인증을 통한 토큰 보상 서비스 오늘의 로그 OLOG

ERC-20 토큰과, NFT 를 이용해 토큰 이코노미 형태의 커뮤니티 서비스를 구축하는 것이 과제였다. 기본적으로 구현해야 할 기능은 커뮤니티 기능(포스트 게시, 댓글 등), 회원가입 및 로그인, ERC20 토큰 주고 받기, NFT 토큰 주고받기 등이 있었다.

우리는 이 기본 기능에 서비스 컨셉을 녹이기로 했다. 클론 코딩을 해야했던 지난 프로젝트와 달리, 이번 프로젝트는 기획의 영역이 커진 것이다.

나는 기본적으로 구현해야 할 기능들을 처음에 봤을 때, 바로 ‘스팀잇’과 ‘스테픈’이 생각났다. 과제를 내준 측에서 요구했던 것은 ‘스팀잇’에 가까웠을 텐데, 다소 식상하게 느껴졌다.

나는 최근에 NFT계에서 핫했던 (지금은 아니지만) 스테픈의 컨셉을 적용해보고 싶었다. 토큰과 NFT와 커뮤니티 세 가지 요소를 다양하게 구성할 수 있는 서비스가 나올 것이라고 생각했기 때문이다. (스테픈 컨셉: 걸음 수에 따라 토큰 채굴, NFT(신발) 구매 시 채굴할 수 있는 토큰 수 강화, NFT는 토큰으로 구매) 팀원들에게 이 컨셉을 설명해주었고, 팀원들 또한 동의를 해주었다.

구조는 스테픈 구조에, 컨셉은 주니어 개발자와 뗄레야 뗄 수 없는, ‘블로깅'이라는 흥미로운 컨셉을 다른 팀원분들께서 제안해주셨다.

그렇게 우리는 블로깅을 한 후 링크를 제출하면 토큰으로 보상을 해주고, 토큰으로 만년필 NFT 구매 시 보상을 강화해주는, ‘O-Log(오늘의 로그)’서비스를 기획하게 되었다.

서비스 설명

메인 화면

• 서비스의 가장 핵심 기능인 ‘블로그 링크 업로드'를 메인에 두었다. (구글 검색창처럼)

  로그인 및 회원가입

• 로그인 시 JWT 토큰을 발급해준다.

마이페이지 - 블로깅 보상 및 댓글 기능

• 블로깅 인증 : 링크만 업로드 해도 이미지, 제목, 파비콘까지 렌더링 해준다. Open graph scraper 모듈을 활용했다. 포스팅 업로드 후 5OLG가 보상으로 주어진다.

• 토큰 sync 기능: 블로그 링크를 업로드할 때마다 토큰을 부여해준다면 온체인에 과열이 생긴다. 이를 방지하기 위해 DB에만 토큰 보상 내용을 저장해두었다가 사용자가 ‘sync’버튼 클릭 시 온체인상에서 그동안 모아둔 토큰만큼 민팅을 해주는 방법을 썼다.

• 댓글 기능: 서비스에 좀 더 interactive한 요소를 주기 위해 다른 사용자와 소통하는 기능을 넣어주고 싶었다. 그게 바로 댓글 기능이고, 타 사용자의 mypage에다 댓글을 남길 수 있도록 하였다.

Explore

• 모든 사용자들이 업로한 모든 블로깅들을 볼 수 있다.
• 사용자 username 클릭 시 해당 사용자의 mypage에 방문할 수 있다.

Marketplace

• 현재 구매 가능한 (아직 구매되지 않은) NFT들을 볼 수 있다.
• 100 OLG가 있어야 구매가 가능하며, 구매와 동시에 NFT가 민팅이 된다.

마이페이지 - NFT 보상 및 강화 기능

• NFT를 보유하고 있다면 한번 블로깅 시 보상이 10OLG로 강화된다.
• NFT를 강화할 수 있다. 기존 NFT는 디폴트 레벨이 1이다. 더 많은 OLG가 있다면 레벨2, 레벨3로 NFT 강화 시도를 할 수 있고, 레벨2는 60%확률로, 레벨3는 30% 확률로 강화할 수 있다.
• NFT가 강화되면 한번 블로깅 인증 시 보상이 레벨2일 땐 20OLG, 레벨3일 땐 더 많은 OLG 보상이 주어진다.

기획 과정

첫 날 2시간이 넘게 회의를 하며 대략적인 기획이 완성되었다. 기본 기능인 블로그 링크 업로드, ERC-20 토큰 보상 기능까지 완료하는 게 첫 번째 주 미션이였다. 두 번째 주부터는 NFT 마켓플레이스 기능을 구체화했고, 댓글 기능도 추가하였다. 이번에는 CSS 요소를 생각하지 않고 figma로 대략적인 위치만 잡고 CSS는 프론트분들이 임의로 해주셨다. figma로 다같이 전체 서비스 구조를 보는 것은 커뮤니케이션 과정에서 매우 필요했다.

역할 분담

1. 프론트 2명
2. 백엔드 1명 (포스트, 로그인, 댓글 등의 기본 API 구현)
3. 백엔드 1명 (스마트 컨트랙트, NFT 관련 API 구현)

4명 중 2명은 프론트, 2명은 백엔드를 맡기로 했다. 다행히 2명이 프론트를 원했고, 2명이 백엔드를 원했다. 1분 만에 역할 분담이 끝났다.

내가 맡게 된 역할: 2번 백엔드

백엔드를 늘 두려워만 했었는데, 최근에 ‘리액트를 다루는 기술’을 참고하며 블로그를 구축하는 실습을 진행하며 Koa와 MongoDB를 접하게 되었다. 기존에 부트캠프에서도 Express와 Mysql을 배우긴 했지만, 정말 이해가 되지 않았는데(오히려 두려움만 증폭됐다;)

실제 서비스를 만들어 보면서 적용해보니 과거에 배웠던 것들이 조각이 맞춰지면서 백엔드 세계의 맛을 보게 되었다. 이해도++ 흥미++ 자신감++이 되었다. 물론 리액트책에서 배운 백엔드가 진짜 백엔드냐?라는 반박이 있을 수 있겠지만, 내 뇌에 백엔드라는 영역이 명확해진 이 순간이, 이 과정이 너무나도 소중했고, 가치가 있었다. 이를 발판 삼아 이번 프로젝트에서 백엔드를 더 공부해보고자 주저하지 않고 백엔드를 지원하였다.

프로젝트가 끝난 지금, 백엔드 구현을 큰 무리없이 재미있게 진행했기에, 나의 도전에 큰 만족을 얻었다. 하지만 고민은 더 커진 것 같다. 내 커리어를 백엔드로 가야 할지, 프론트로 가야 할지 말이다. 둘 다 저마다 매력이 있음을 깨달았기 때문에 선택이 더 어려워진 것 같다.

깨달은 점

“완벽한 팀워크는 유니콘과도 같다.”

과거의 나는 완전무결한 협업을 꿈꿨다. 팀 구성원 간 충돌이 없어야 하고, 커뮤니케이션도 활발해야 하고, 팀원 간의 분위기가 좋아야 한다. 적어도 내가 팀장일 때는 더더욱 그래야 했다. 나는 내 특유의 아이스브레이킹 능력, 상대방의 성격과 스타일에 맞춰 나 자신을 바꾸는 능력에 능하다고 생각했기 때문에 어떤 조직이든 어떤 사람이든 다 완벽한 협업을 할 수 있을 것이라고 생각했다.

하지만 그 믿음은 반복되는 팀 프로젝트를 겪으면서 깨졌던 것 같다. 어떻게 항상 완벽한 팀워크가 있을까. 이제 그런 환상을 버리고, 최소한 나로 인해 팀에 부정적인 영향을 주지 않도록 힘을 써야겠다고 생각했다.

이번 팀 프로젝트도 마찬가지였다. 우리 팀의 협업 방식은 다소 사무적이고 딱딱했다. 100% 만족스러운 커뮤니케이션 방식은 아니었지만, 다른 팀들의 결과물과 비교해봤을 때 우리 팀의 협업이 그나마 최고의 수준이었던 거 같다.

“실력이 다가 아니다. 같이 일하고 싶은 사람이 되어야 한다.”

다양한 분들을 만나고, 다른 팀들은 어떻게 했는지 들으면서 개발 실력이 아무리 좋아도 같이 일하기 싫은 사람만큼 매력 없는 사람이 없다는 생각이 들었다. 나는 같이 일하고 싶은 사람이 되고 싶다. 물론 실력도 중요하지만, 혼자서 살 수는 없는 세상, 협업 능력이 개발자로서 최고의 덕목이 아닐까 싶다.

이제 돌아오는 월요일부터 새로운 프로젝트가 시작된다. 팀장을 원하는 사람들이 아이템과 함께 발표를 진행한다. 나는 팀장이 될 것이다. 팀장이 된다는 것. 그것도 이 코스에서 가장 중요한 프로젝트3의 팀장이 된다는 것은 너무나도 긴장되는 일이다. 프론트, 백엔드 도전을 넘어서 더 어려운 도전이 될 듯 하다. 다음주도 파이팅이다.

• useEffect는 리액트 컴포넌트가 렌더링될 때마다 특정 작업을 수행하도록 설정할 수 있는 Hook

• 클래스형 컴포넌트의 componentDidMount와 componentDidUpdate를 합친 형태

1. 기본적으로 첫 번째 파라미터(함수)가 렌더링된 직후 실행

2. 마운트될 때만 실행하고 싶을 때 (업데이트 될 때는 실행 X) → 두 번째 파라미터로 비어있는 배열을 넣어줌

3. 특정 값이 업데이트될 때만 실행하고 싶을 때→ 두 번째 파라미터에 의존 배열(deps)를 넣어줌

4. 컴포넌트가 언마운트되기 전이나 업데이트 되기 직전에 작업을 수행하고 싶다면 뒷정리 함수(cleanup)를 반환해 주어야 함.

사용 예시 category의 값이 바뀔 때마다 뉴스를 새로 불러와야 하기 때문에 useEffect의 의존 배열에 category를 넣어 줌

2. useMemo

Memo, “memoized”, 이전에 계산한 값을 재사용한다는 의미. 함수 컴포넌트 내부에서 발생하는 연산을 최적화할 수 있음.

첫 번째 파라미터에 함수(어떻게 연산할지 정의)를 넣어줌. 두 번째 파라미터에 deps 배열 (어떤 값이 변할 때 새로 호출해야 하는지 명시)을 넣어줌. useMemo는 특정 결과값을 재사용할 때 사용, useCallback은 특정 함수를 새로 만들지 않고 재사용하고 싶을 때 사용

3. useCallback

• useMemo와 비슷한 Hook

• 주로 렌더링 성능을 최적화해야 하는 상황에 사용하며, 특정 함수를 새로 만들지 않고 재사용하는 기능을 함.

1. 첫 번째 파라미터에 생성하고 싶은 함수를 작성, 두 번째 파라미터에 배열 (어떤 값이 변할 때 함수를 새로 생성해야 하는지 명시)을 작성
2. 두 번째 파라미터(deps)에 비어있는 배열을 넣은 경우, 컴포넌트가 처음 렌더링될 때만 함수 생성, 이후 재사용 주의할 점! 함수 안에서 사용하는 상태 혹은 props가 있다면, 두 번째 파라미터(deps)에 포함시켜야 함. 만약 넣지 않으면, 함수에서 해당 값을 참조할 때 가장 최신값을 참조할 것이라고 보장할 수 없음.

4. useReducer

• useState보다 더 다양한 컴포넌트 상황에 따라 다양한 상태를 다른 값으로 업데이트 할 때 사용

• 현재 상태, 업데이트를 위해 필요한 정보를 담은 액션 값을 전달받아 새로운 상태를 반환하는 함수

첫 번째 파라미터: reducer 함수, 두 번째 파라미터: reducer의 기본 값 (initialState)

state: 현재 가리키는 상태, dispatch: 액션을 발생시키는 함수 reducer 함수: 현재 상태(state)와 액션 객체(action)를 파라미터로 받아와서 새로운 상태를 반환해주는 함수

첫 프로젝트 치곤 백엔드-프론트-블록체인을 모두 아울러야 하는 어려운 프로젝트였지만 인간은 역시 적응의 동물. 그 어려운 것도 결국 완료를 해버렸다… 역시 못 할 것은 없다. 물론 계획했던 기능은 모두 구현하지 못해서 아쉬움이 남는다.

원래 4명이서 진행하는 프로젝트를 우리 팀은 사정상 2명이서 진행을 하게 되었다. 다른 3명팀과 합쳐서 5명이 진행한다는 옵션도 있었지만 이번 프로젝트에서 협업 능력보다 개발 역량을 더 높이고 싶다는 욕심이 있었다. '그래 내가 덜 자면 되지'라는 생각으로 결국 2명이서 진행을 하게 되었다.

프로젝트가 마무리된 지금…. 난 나쁘지 않은 선택이였다고 생각한다.

프로젝트 레포지토리: https://github.com/codestates/beb-04-97s

프로젝트 주제

프로젝트 주제는 NFT 거래 플랫폼, 'OpenSea 클론 코딩'하는 것이었다. 주어진 것은 메타마스크 지갑 연결 코드, mint 함수, 발행된 NFT 가져오는 코드 등이 있었고, 이것을 활용해서 구현을 했으며, 구현 범위는 팀의 자율이었다.

팀 이름은 97s!

그렇다 공교롭게도 유일한 팀원이자 팀장인 친구가 나랑 동갑이었다. 팀 이름을 closesea, openmountain, underthesea 등을 생각해냈지만, 97년생이 만난 우연이 신기해서 97s라 짓게 되었다. 팀장 친구는 컴공과 출신으로 프로젝트 경험과 개발 경험이 많았기 때문에 의논 하에 팀장이 되었고 나는 팀원이 되었다.

역할 분담

• Front End
  • 리액트로 페이지 구성 (라우트, 변수 상태 관리, 인터랙션 등)
  • CSS

• Back End
  • 몽고DB 세팅
  • express모듈로 Front와 DB 통신
• Contract, Web3 handling
  • remix로 컨트랙 배포
  • web3로 컨트랙 함수 활용

사실 2명이라서 칼같이 역할을 자르진 않았다. 프로젝트 직전까지 리액트 공부를 혼자서 해왔기 때문에 내가 프론트와 web3를 위주로 했으며 팀장 친구는 백엔드를 맡았고, 내가 프론트에서 구현이 어려웠던 부분을 구현해주었다.

준비 과정

피그마를 활용해 우리가 구현할 페이지를 빠르게 그려 보았다. 미리 그려 두니 깔끔한 페이지를 구현하는데 많은 도움이 되었다. 물론 저것 그대로 진행은 안 됐지만, 80% 정도는 맞춘 것 같다. 피그마를 활용하니 CSS 설정에 들어갈 정보를 가져오기도 편했다.

구현 기능

Home, Navigator Bar

메타마스크 지갑이 연결되어 있지 않으면 wallet 아이콘을, 연결되어 있으면 'My Page'가 표시되도록 하였다.

Explore

해당 컨트랙 상에서 배포한 모든 NFT들을 볼 수 있다.

발행된 NFT를 가져오는 코드는 주어졌기 때문에 어렵지 않았다. 주어진 코드는 마이페이지에서 자신이 발행한 NFT들만 볼 수 있게 하는 코드였기 때문에 전체 NFT를 렌더링하기 위해서는 약간의 수정이 필요했다. 그것을 수정해서 구현하는 것은 어렵지 않았다.

그러나 web3를 이용해 NFT들을 렌더링하는 것은 굉장히 오랜 시간이 소요되었다. 그래서 우리는 백엔드를 개발해 자체 데이터베이스를 만들어 그곳에서 가져오는 방식을 사용하기로 했다. 비록 NFT 데이터를 온체인과 오프체인 두 군데에서 독립적으로 관리하는 것이 굉장히 번거롭긴 하지만, 기존 방식에 비해 더 빠른 렌더링을 구현할 수 있었다.

Create

NFT 민팅 기능

• Image 업로드, NFT 이름 입력, 설명 입력, 판매 여부(true일 경우 가격을 설정할 수 있다.) 를 설정한다.
• 메타마스크로 가스비를 지불하면 민팅이 완료된다.

workflow 민팅된 NFT는 온체인과 오프체인(자체 Database) 두 곳에 차례로 저장되게 했다.

• 사용자 입력 > Create 버튼 클릭 (만약 지갑 연동이 안 되어 있다면 이후로 진행이 안 됨)
• 이미지 파일은 IPFS url로 변환 후 메타데이터에 넣어 주어 메타데이터를 완성한다.
• 온체인: mint함수 (지갑 주소, IPFS url)
• 오프체인: post 요청을 보내 완성된 메타데이터를 자체 Database에 저장

create 버튼 클릭 시

IPFS url 변환 코드 IPFS 변환은 정말 어려웠는데 하고 나니 간단했다;; 해당 링크를 많이 참고했다.

자체 database에 들어가는 Metadata

• _id: 몽고 DB에서 자체적으로 부여하는 id
• address: NFT를 민팅한 주소, owner
• name: NFT 이름
• ercURL: IPFS에서 변환한 url
• createdAT: 민팅한 시각
• description: create 할 때 작성하는 설명
• sellType: 판매 여부 (판매하지 않고 민팅만 해도 된다.)
• sellPrice: NFT 가격
• tokenHash: mint 함수 진행 후 리턴값, tokenId

web3를 이용해 구현한 민팅함수 web3 공식 문서를 참고하면서 작성을 해보았다. 작성을 다 하고 테스트를 할 때 메타마스크가 뜨는 순간의 감격은 이루어 말할 수 없다.

My page

My page에서는 자신의 Address를 보여주고, 자신이 민팅한 NFT들을 보여준다. Address는 App.js 에서 web3를 이용해 가져오고, 그것을 props로 my page에 전달을 해준 값을 그대로 렌더링했고, 민팅된 nft들은 기존 온체인에 있는 데이터들을 가져오는 방식으로 구현됐었지만, explore와 마찬가지로 자체 데이터베이스에서 데이터를 가져오는 방식으로 진행했다.

Info

NFT를 클릭하면 보여지는 페이지. NFT이름, 설명, 가격 등을 볼 수 있다. 만약 판매자가 판매 여부를 false로 해두었다면 BUY NOW 버튼은 비활성화된다. 여기서 BUY NOW 버튼을 클릭하면 Buy 기능이 실현되는 것까지 구현을 하고 싶었으나, 구현을 하지 못해 아쉬웠다. 프로젝트를 사실상 끝내고 정리를 해야했던 금요일 오후3시까지 붙잡고 있었지만 결국 프로젝트 마무리를 위해 포기해야만 했다. 구매까지는 정상작동 되었지만, nft를 transfer하는 함수가 작동이 되지 않았다. 이것은 컨트랙트단 코드의 문제였는데, 해당 코드를 진행하는 주체가 nft를 주는 사람이 아닌 받는 사람이었기 때문에 approved가 되지 않아 실행이 되지 않은 것으로 추정이 되고, 해당 조건 여러번 수정하면서 다시 컨트랙을 배포 후 여러차례 테스트를 해보았을 때에도 오류가 잔뜩 떴고, 이미 여기까지 구현하는데에도 수많은 에러들과 수정을 거치면서 체력을 다 소진했고, 마감 시간은 이미 한참 지난 후였기 때문에 더 이상의 진행이 불가하다고 판단을 내렸다.

개발 회고

막막했지만 결국 마무리는 했다.

프로젝트 기간이 3일(+0.5일)이었는데 이틀째까지는 프로젝트 감을 잡고 프론트로 틀을 잡은 것이 다였다. 하지만 그 이후부터 감을 잡고 하루 이틀만에 고도화된 기능을 구현하는데 성공을 할 수 있었다. 이틀을 감 잡는 시간으로 사용한 게 아까웠지만, 결국엔 필요한 시간이었고, 소중한 시간이었다고 생각한다.

워라밸에 대한 고민.

2인 프로젝트로 확정이 되면서 내가 잠을 줄이면서 더 열심히 해야겠다고 생각을 했기 때문에 하루에 3-4시간씩 자면서 프로젝트를 진행했다. 9시-10시에 카페에서 팀장 친구를 만나 알바 전까지 모각코를 하고, 알바 4시간, 집 돌아와서 밤 늦게까지 또는 새벽에 일어나서 코딩, 이러한 과정을 3일 내내 진행했는데, 그래서 진행하는 내내 몸이 피곤하고 힘들었다. 이게 맞는 것인가, 지속가능한 것인가를 고뇌하며 다음 프로젝트는 좀 더 시간이 많이 주어지니 밸런스를 잘 맞추면서 진행해야겠다.

다듬어지지 않은 코드

CSS는 물론, 함수들을 분리하지 않고 코드를 짜서 코드 페이지가 한 페이지에 300페이지가 넘는 엉망진창인 코드가 되었다. 코드를 짜는 사람이 두명밖에 없었기 때문에 분리를 하지 않았어도 식별을 할 수는 있었지만, 유튜브나 이런 저런 개발 커뮤니티에서 하지 말라는 코드의 정석과도 같았다. 마음이 급해서 이걸 제대로 정리하면서 진행해야겠다는 생각이 뒷전이었고, 기능 구현하느라 급급했던 것 같다. 다음 프로젝트에서는 4명이 진행할 예정이니 좀 더 모듈화를 해보는 연습을 해봐야겠다.

🔆 과제 선택 이유

가장 모르는 주제였고, 가장 학습이 부족했던 파트였다.

첫 번째 과제에 힘을 너무 많이 주는 바람에 두 번째 과제를 빨리 끝낼 수 있는 쉬운 주제로 선택하려고 했다.

하지만, 과제 주제를 선택하려고 리스트를 살펴 보면서, 어느 정도 도전적이면서도 내가 과제를 진행하면서 배울 수 있는 게 더 많은 것을 선택하는 게 낫겠다 싶어 선택하게 되었다.

🔆 KAS(Klaytn API Service)란?

클레이튼 블록체인 네트워크를 API로 제공하는 서비스이다. 이더리움 노드에 접근하기 위해 infura를 사용했던 것처럼, KAS를 통해 클레이튼 노드에 참여할 수 있다. 즉, REST API로 클레이튼 트랜잭션에 대한 조회와 전송이 가능하다.

🔆 caver-js

이더리움과 상호작용하는 클라이언트를 개발하는데 Web3.js를 사용했던 것처럼, caver-js는 Klaytn 노드와 상호작용할 수 있도록 하는 자바스크립트 API 라이브러리다.

caver-js 에는 다음과 같은 패키지들이 있다.

• caver.account : Account 관련 기능을 제공하는 패키지
• caver.wallet.keyring : 주소와 개인키를 포함하는 키링 관련 기능을 제공하는 패키지
• caver.transaction : 트랜잭션 관련 기능을 제공하는 패키지

이번 과제에서는 위의 패키지 위주로 사용했으며, 이 밖에도 공식문서에서 더 많은 패키지를 확인할 수 있다.

🔆 과제 진행 순서

• 환경설정 : kasPractice 폴더 생성 → npm init → npm i express → npm i caver-js → index.js 파일 생성→.env 파일 생성 (ADDRESS, PRIVATE_KEY)
• http://localhost:8080/ 에 접속해 서버 구현 확인
• getblock 클래스로 가장 최근 블록 정보 가져오기
• getBalance 클래스로 계정 잔고 확인하기
• getAccount 클래스로계정 정보 확인하기
• valueTransfer 클래스로 다른 계정에 클레이 전송하기

전체 코드: https://github.com/mae-zung/learn_solidity/tree/master/kasPractice

🔆 서버 구현 확인

🔆 getblock 클래스로 가장 최근 블록 정보 가져오기

getblock은 아무런 인자를 넘겨주지 않을 경우 가장 최근에 생성된 블록 넘버를 리턴한다.

🔆 getBalance 로 계정 잔고 확인하기

입력으로 받은 주소의 잔고를 반환한다. 다만 해당 함수를 사용할 경우 "Peb" 단위로 반환되므로, "KLAY"로 반환하려면 convertFromPeb을 사용해 단위를 변경해준다.

🔆 getAccount 클래스로 계정 정보 확인하기

입력으로 받은 주소의 계정 정보를 반환한다. 주소를 쿼리 파라미터로 넘겨줄 경우 다음과 같이 계정에 대한 정보를 리턴해준다.

🔆 valueTransfer 클래스로 다른 계정에 클레이 전송하기

• receiver: 클레이를 전송할 주소
• amount: 전송할 클레이의 양 클레이를 전송하기 위해 클레이를 보낼 주소의 잔고를 조회한 후, 전송할 값보다 잔고의 양이 더 많은지 확인하고 전송을 실행한다.
• keyring: 계정 주소와 개인키를 포함하는 구조로 클레이튼 계정을 사용해 서명할 수 있는 기능인데, 그 중createFromPrivateKey는 개인키를 인자로 받아 SingleKeyring 인스턴스를 생성해준다.
• valueTransfer: KLAY를 전송할 때 사용한다. 트랜잭션 객체를 인자로 전달한다.
• valueTransfer.sign(keyring): keyring을 이용해 만들어진 트랜잭션을 서명한다.
• sendRawTransaction(signed): 트랜잭션을 클레이튼 블록체인 플랫폼으로 보낸다.

정상적으로 클레이 전송이 진행되었음을 확인하였다. https://baobab.klaytnfinder.io/account/0x01776f5b6db13fc38e36c56896c8ad24abf18bc4

🔆 개발 회고

짧은 시간이었지만, 아예 몰랐던 API service로 서버 구현하는 방법을 조금이나마 이해할 수 있게 되었다. 이 정도면 과제 초반에 잡은 목표를 어느 정도 달성했다고 볼 수 있을 듯 하다. 포스트맨도, .env파일, gitignore, express 등 이전에 공부했던 것들을 활용하면서 복습할 수 있었던 점이 가장 좋았고, 무엇보다도 다음 주부터 진행될 프로젝트에 많은 도움이 되지 않을까 싶다. 라이브러리 내 많은 클래스들을 써보지 못해 아쉽긴 하지만, 프로젝트를 진행하면서 더 다양한 것들을 사용해볼 수 있지 않을까 기대해본다.

🔆 REFERENCE

https://github.com/klaytn/caver-java/blob/dev/README.md https://ko.docs.klaytn.foundation/dapp/sdk/caver-js#packages-in-caver-js https://www.npmjs.com/package/caver-js

블록체인 실습을 진행하는 과제를 받았다. 다양한 주제들 중 나는 ‘DID를 활용한 백신접종증명서 개발'을 선택하였다. 그 이유는 다음과 같다.

• DID는 블록체인 기술 중 현재 실생활에서 접목이 많이 되고 있는 기술이며 (특히 백신접종증명서는 전국민이 질리도록 사용했지 않은가?)
• 해당 과제를 진행하면서 솔리디티 언어를 좀 더 많이 이해할 수 있게 되지 않을까 생각했다.
  

🔆 백신접종증명 시나리오 설계

진행하기에 앞서,

DID, 검증가능한 크레덴셜 등의 개념을 알고 크레덴셜 발행구조와 그 흐름을 알고 있는 것이 중요하다.

이전에 DID를 공부하면서 정리한 것을 참고하였다.

포스팅 마지막에 일반 DID 기술 플로우에 백신접종증명 사례를 대입해본 절차를 정리해두었는데,

해당 내용을 바탕으로 컨트랙트를 설계해 보았다.

기존 DID 신원절차와 방식을 다음과 같이 단순화 하였다.

1. 주체는 동일하다. Holder (개인), Issuer (질병관리청), Verifier(다중이용시설) 로 설정하였다.
2. 모든 Holder들의 Credential을 보관하는** IPFS (분산 저장소)** 와, 개인이 자신의 Credential을 저장할 수 있는 Personal Mobile을 설정해주었다.
3. 순서는 아래와 같으나, 1번: ‘Holder가 Issuer에게 Credential 발급을 요청’은 구현이 복잡해 오프체인에서 진행된다고 가정하였다.

🔆 전체코드

Github: https://github.com/mae-zung/learn_solidity/blob/master/vaccineCredential.sol

// SPDX-License-Identifier: GPL-3.0
pragma solidity 0.8.10;

contract Covid19VaccineCredential {
    address private issuerAddress;
    uint256 private idCount;
    mapping(uint8 => string) private vaccineType;

    struct Credential{
        uint256 id;
        address issuer;
        uint8 vaccineType;
        string date;
    }

    mapping(address => Credential) private credentials;
    mapping(address=>Credential) public IPFS;
    mapping(address=>Credential) private personalMobile;

    constructor() {
        issuerAddress = msg.sender;
        idCount = 1;
        vaccineType[0] = "Pfizer";
        vaccineType[1] = "Moderna";
        vaccineType[2] = "Astrazeneca";
    }

    // Issuer - 크레덴셜을 발급해줌.
    function issueCredential(address _holderAddress, uint8 _vaccineType, string calldata _date) public returns(bool){
        require(issuerAddress == msg.sender, "Not Issuer");
                Credential storage credential = credentials[_holderAddress];
        require(credential.id == 0);
        credential.id = idCount;
        credential.issuer = msg.sender;
        credential.vaccineType = _vaccineType;
        credential.date = _date;

        idCount += 1;

        registerCredential(_holderAddress);

        return true;
    }

    // Holder - 크레덴셜을 받아와서 자신의 모바일에 저장함.
    function getCredential(address _holderAddress) public returns(bool){
        Credential memory mobileStorage = credentials[_holderAddress];
        personalMobile[_holderAddress] = mobileStorage;
        return true;
    }



     // Issuer - 발급한 크레덴셜을 IPFS에 등록함.
    function registerCredential (address _holderAddress) internal {
        Credential memory ipfs = credentials[_holderAddress];
        IPFS[_holderAddress]=ipfs ;
    }

    // Holder - 크레덴셜을 위조, 변조함.
    function tamperCredential (address _holderAddress, uint8 _vaccineType, string calldata _date) public{
        Credential storage tampered = personalMobile[_holderAddress];
        tampered.vaccineType=_vaccineType;
        tampered.date=_date;

    }

    function hash(uint256 _id, address _issuer, uint8 _vaccineType, string memory _date) pure internal returns(bytes32) {
     return keccak256(abi.encodePacked(_id,_issuer,_vaccineType,_date));
}

    // Verifier - 제출받은 크레덴셜과 IPFS에 등록된 크레덴셜을 비교함.
    function verifyCredential (address _holderAddress) view public returns(bool){

        Credential memory holderCredential = personalMobile[_holderAddress];
        Credential memory ipfsCredential = IPFS[_holderAddress];

        bytes32 fromHolder = hash(holderCredential.id, holderCredential.issuer, holderCredential.vaccineType, holderCredential.date);
        bytes32 fromIpfs = hash(ipfsCredential.id, ipfsCredential.issuer, ipfsCredential.vaccineType, ipfsCredential.date);

        if(fromHolder==fromIpfs){
            return true;
        }else return false;

    }



}

🔆 코드 해설

1. 검증가능한 Credential 구조체

• id: index 순서
• issuer: 발급자
• vaccineType: 백신 타입 (화이자, 모더나, 아스트라제네카)
• date: 백신을 맞은 날짜

2. 맵핑 타입의 변수 선언

• credentials: 크리덴셜이 발행될 때 사용하는 변수
• IPFS: IPFS에 저장되는 크리덴셜
• personalMobile: 개인의 휴대폰에 저장되는 크리덴셜

개인 공간에 크리덴셜을 저장하는 방법을 위와 같이 단순화하였다.

3. Issuer - issueCredential 함수 issueCredential 함수를 통해 issuer는 holder에게 크리덴셜을 발행해준다. 발행 후 크리덴셜을 IPFS에 저장시켜주는 registerCredential 함수를 실행시킨다.

4. Issuer - registerCredential 함수

registerCredential 함수를 통해 issuer는 ipfs에 발행한 크리덴셜을 등록한다.

5. Holder - getCredential 함수

getCredential 함수를 통해 Holder는 자신의 personal mobile에 크리덴셜을 저장한다.

6. Verifier - verifyCredential 함수, hash 함수

verifyCredential 함수를 통해 Verifier는 holder가 갖고 있는 personal mobile 내의 크리덴셜 값과 공개되어 있는 IPFS에 해당 holder에 대한 크리덴셜 값을 해싱하여 비교한다. 동일할 경우 true를, 다를 경우 false를 반환한다.

Verifier가 검증을 하는 방식은 정말 많고 복잡하다. (참고) 위 방식은 내가 임의로 구현해준 방식이다.

솔리디티에서 해싱은 keccak256을 주로 사용하고, abi.encodePacked는 인코딩을 위해 사용한다. 따라서 우선 크리덴셜 값들을 인코딩하고, 해싱을 해주었다. 만약 데이터가 털끝이라도 바뀐다면 해싱값은 완전히 바뀔 것이다.

인코딩 과정을 거치지 않고 해싱을 바로 진행해도 되지만, 데이터를 보호할 목적이 있다면 지양하는 것이 좋다.

솔리디티에서의 해싱과 인코딩 관련 내용은 이 곳을 참고했다.

7. (option) Holder - tamperCredential 함수

이 함수는 Holder가 자신의 크리덴셜 값을 위, 변조하는 함수다. 백신의 종류와 날짜를 파라미터로 받아서 변경할 수 있도록 하였다.

좀 더 다이나믹한(?) 구현을 위해 추가를 해본 기능이다. 크리덴셜을 검증할 때, 두 값이 항상 같은 경우만 나올 것이라서, 예외 상황을 주고 싶었다.

🔆 동작 과정

컨트랙주소: 0x6c58023f14b627E6a8F36650CD47cA495c57D4CC 네트워크: Rinkeby 테스트 네트워크 이더스캔 주소: https://rinkeby.etherscan.io/address/0x6c58023f14b627E6a8F36650CD47cA495c57D4CC

1. 코드 작성 후 배포

2. issueCredential 함수 실행

이미 holder의 credential 정보가 오프체인에서 검증되고 전달되었다는 가정 하에 진행된다. holder의 주소, 백신 타입(0: 화이자, 1: 모더나, 2: 아스트라제네카), 백신 맞은 날짜를 파라미터로 전달해주어 크리덴셜을 생성한다.

3. IPFS에 크리덴셜이 제대로 저장이 되었는지 확인

issueCredential 함수 실행 시 마지막에 registerCredential 함수가 실행된다. 해당 함수 실행 시 크리덴셜 정보가 공개된 IPFS에 저장되기 때문에 IPFS에 holder의 주소를 인자로 넣으면 크리덴셜을 확인할 수 있다.

4. getCredential 함수 실행

getCredential 함수를 실행시켜 holder가 자신의 personal mobile에 크리덴셜을 저장할 수 있도록 한다. personal mobile은 private이기 때문에 크리덴셜 내용을 확인할 수 없다.

5. verifyCredential 함수 실행

Verifier가 personal mobile 내의 credential 값이 유효한지 판단 후 true or false 값으로 리턴한다. 위의 경우에서는 두 값이 같기 때문에, true 값이 나왔다.

(Holder가 자신의 크리덴셜을 위,변조한 경우)

6. tamperCredential 함수 실행

백신 타입을 1 → 2로, 날짜를 21.10.3 → 22.01.12로 변경하였다.

7. verifyCredential 함수 실행

verify 해본 결과 false를 리턴하였다.

이렇게 Holder, Issuer, Verifier 세 주체를 중심으로 한 코로나19 백신접종증명 시스템을 약식으로 구현해보았다.

🔆 개발 회고

하루라는 짧은 시간 안에 약식의 시나리오를 구현하려고 했기 때문에 간소화하고, 생략하는 과정들이 많았다.

• 암호화하지 못한 채로 정보를 주고받은 점

• 사용자 개인 저장 공간을 구현하지 못한 점

• 상속, Modifier 등의 다양한 솔리디티 기능을 활용해보지 못한 점

  등이 아쉬웠다. 하지만 100을 구현하기 위해 120을 알아야 한다는 것처럼, 해당 과제를 구현하기 위해 그 이상의 것들을 찾고, 공부해야 했고, 그 과정에서 배워가는 점이 많았다.

기존에 issueCredential 코드와 getCredential 코드만 있던 상태에서 함수를 더 추가해 최소한의 시나리오가 진행될 수 있도록 설계하였다.

늘 주어졌던 솔리디티 코드를 복붙하는 것을 넘어서, 내가 직접 구조를 설계하고 코드를 작성, 실행시켰던 게 가장 뿌듯한 경험이었다.

최소한의 기능만 구현해서 빠르게 과제를 마무리하는 것이 목표였는데, 하다보니 계속 욕심이 생겼다. 기존에는 크리덴셜을 발급하고 개인 모바일에 저장하는 것까지가 목표였으나 verify 과정이 추가되었고, tamperCredential 함수와 Hash 함수까지 추가되었다. 아마 시간이 더 주어졌다면 엄청난 것(?)을 구현했을지도 모른다.

🔆 Reference

https://www.slideshare.net/JaehoonJShim/ssi-introduction

https://ssimeetupkorea.github.io/vc-data-model/#core-data-model

https://ncv.kdca.go.kr/menu.es?mid=a12502000000

https://medium.com/0xcode/hashing-functions-in-solidity-using-keccak256-70779ea55bb0

🔆 알고리즘 41번 문제 - 해결 완료!

사실 41번 문제는 어제 해결하려고 어제부터 켜 놓았는데, 도저히 접근 방법이 떠오르지 않았다. 요즘 코플릿 왤케 어렵지? 라고 생각하면서 일단 꺼 두었고, 오늘 아침 다시 펼쳐보았다. 오늘 아침도 어제와 비슷한 방식의 접근 방법에서 벗어나지 못하다가, 레퍼런스를 그냥 봐 버릴까 고민도 잠깐 하다가, 갑자기 딱! 해결방법이 떠올랐다. 그걸로 쭉 진행했더니 결국 풀려버렸다. 그것도 아주 빠르게... 살짝 허무했다. 나에게 하루의 기회를 더 준 결과인 것일까. 레퍼런스 코드를 봤는데 내 코드와 거의 똑같았다. 생각해보니 정말 쉬운 문제였다. 왜 이런 문제에 처음부터 쫄아버렸지? countIslands.js

🔆 리액트 학습

리액트 교재 5장(ref), 6장(컴포넌트 반복), 7장(컴포넌트의 라이프사이클 메서드)를 학습했다. 6장은 이미 배웠던 내용이라 아주 재밌게 진행을 했는데, 5장과 7장이 도저히 이해가 되지 않았고, 뚜렷하게 어떤 기능 구현 시 필요한 개념인지 잡히지가 않아 더 집중이 되지 않았다. 컴포넌트와 라이프사이클 메서드를 제대로 정리해둔 블로그 글을 우선 킵해둔다. 구현할 때는 이벤트 관리나 Hooks 등이 중요하겠지만, 리액트에 대한 딥한 개념을 알고있는 것도 중요하다고 생각한다. (면접 때 물어볼 것 같다.)

🤔 취뽀 경험글을 우연히 읽었다.

벨로그 트렌딩을 보다가, 프론트엔드 개발자로 취업한 분의 글을 읽게 되었다. 내가 프론트엔드 직무에 관심이 많기 때문에 참고하면 좋을 것 같아 읽기 시작했고, 보는 내내 취준의 과정을 간접적으로 체험할 수 있어 숨 막히는 기분이었다. 과거에 문과 취준을 해본 경험이 떠오르며 정말 정말 숨이 막혔다.

물론 내용들은 도움이 많이 되었다. 나는 이제 개발 공부를 시작한지 4개월 밖에 안 됐기 때문에, 아직 취준을 할 수 있을 정도로 여러모로 성숙되지도 않아 아직 본격적인 취업 준비를 하고 있지는 않다. 하지만 나중에 취준을 할 때 필요한 것들을 미리 알고있자는 관점에서, 내가 어떤 부분들을 중요하게 관리해야 하고, 준비해야 할 지의 방향성 등을 잡을 수 있었다.

🤔 블로그 이사가 하고 싶어졌다.

오늘 구글링을 하며 다른 개발자들의 블로그를 보다가 너무나도 내 스타일인 블로그를 발견했다. 사실 이미 티스토리에서 벨로그로 이사 온 건데, 또 이사를 해야하나 싶었다. 아직 개발 경력 3개월인데 바꾸려면 지금 바꾸는 게 좋지 않나....

💻 2022.06.03

🔆 블로그 이사 시도

어제 너무나도 내 스타일이었던 블로그를 찾게 되었고, 최근에 벨로그에 대한 불만이 차츰 차츰 쌓여가면서 블로그 이사를 하기로 결정하였다. 바로 gatsby를 활용한 깃허브 블로그였는데, 블로깅을 하면 커밋도 되고, 기존에 있는 테마에 리액트로 내가 원하는 기능을 추가하고 포맷을 수정할 수 있다는 게 너무나도 매력적이었다. 그러나 그 과정은 순탄치 않았다. image를 처리하는 sharp라는 모듈이 골머리를 썩혔다. npm install 마저 되지 않았기 때문이다. node 버전을 downgrade하고 별의 별 짓을 다 해서 결국 install까지 갔지만, 깃허브에서 자동 배포를 하는 설정을 하다가 망했고, 어떤 브랜치에 어떻게 올려서 어떻게 포스팅을 해야하는 지도 완전히 혼란스럽고 엉켜버려서 결국엔 다 밀어버리고 포기했다. 6시간 반이 지난 시간이었다. 그래서 제대로 학습도 하지 못했으며 현타만 쎄개 왔다. 하지만 나는 포기하지 않을 것이다. 우선은 다른 학습이 더 중요하기 때문에 이번은 포기하지만, 다음에 시간이 생기면 다시 도전을 할 것이다.

🔆 폴리곤 밋업

지난번에 민우님의 추천으로 폴리곤 밋업에 참여하게 되었다. 생각보다 많은 사람들이 왔고, 폴리곤의 테스트넷과, 리액트를 이용해 민팅하는 컨트랙을 작성하여 오픈씨 테스트넷에 NFT를 올리는 과정을 진행했다. 부트캠프 과정 중에서 이더리움 테스트넷으로 자주 실습을 진행해봤기 때문에 이더리움에서 폴리곤으로 바꼈을 뿐 그 과정이 그다지 낯설지 않았다. 끝나고 함께 참여한 동기분들 3분과 함께 뒷풀이 시간을 가졌다. 나는 오히려 이 시간이 더 기억에 남는다. NFT에 대한 이해도가 높은 동기분들과 토큰 이코노미에 대하 진지한 성찰의 시간(?)을 갖고 다들 어떤 것을 지향하는지, 어떻게 그것을 지향하게 되었는지를 토론하였다. 원래 친구들과 종종 안 진지한 얘기만 했는데, 페어분들의 진지한 얘기를 들으며 나의 방향성도 다시 한번 점검해 보는 계기가 되었다.

💻 2022.06.05

🤔 문득 나의 문제점에 대해 고찰하다

나는 학습 기억력이 안 좋은 것 같다. 1-2주 전에 배운 내용들이 잘 기억에 남지 않는다. 그 지식을 얻는데 들인 시간이 아깝다. 내가 작년에 코인 가치투자를 위해 블록체인을 배우며 아이패드에 기록했는데, 최근에 그 내용을 보면서 깜짝 놀랐다. 최근에 공부한 내용들과 너무 겹쳤기 때문이다. 최근에 블록체인 이론 공부를 할 때 전혀 생각이 나지 않았고, 처음 보는 내용들이었다. 아.. 이래서 내가 깊이가 없는걸까? 쌓이는 게 없어서?

💻 2022.06.06

🔆 리액트 학습

오늘 드디어 투두리스트를 만드는 실습을 했다. 1. 할 일 입력 후 리스트에 추가하는 기능 2. 리스트에서 삭제하는 기능 3. 체크박스를 체크하면 빗금과 함께 체크 표시 (또는 그 반대)가 되는 기능 등을 구현했다. 이전까지는 어떤 Hooks들이 있고, css는 어떻게 설정하고 등을 배워서 살짝 지켜웠었는데, 드디어 그럴듯한 실습을 하게 되어 재밌었다. 진도를 빨리 나가서 얼른 블로그 만드는 실습까지 진행하고 싶다.

🔆 마음이 급하다 급해!!

프로젝트 기간까지 벌써 한 주 남았다. 금요일에 동기분들을 만나고 난 이후로 마음이 많이 급해졌다. 프로젝트가 시작되고 역할 분담을 할 때 쓸모있는 사람이고 싶은데 쓸모가 없을까봐 불안해서, 그나마 잘 할 수 있는 리액트를 얼른 끝내버리고 싶다. 한 주 안에 리액트 책을 끝까지 떼는 게 나의 목표다.

💻 오늘 진행한 것

• 리액트 공부 시작

지난 30일에 구입한 리액트 책을 제대로 펼쳐서 하나하나 실습하기 시작했다. 4장까지 실습 완료했다. 정리하면서 감당하지도 못할 일들에 욕심이 생겼다. 하면서 깨우친 것들을 하나한 정리하고 싶다는 욕심. 하지만 지금 TIL도 그날그날 제대로 못 쓰는데 리액트 정리라고 제대로 할 수 있을까?

리액트는 부트캠프 섹션1, 섹션2에서 자주 다뤘기 때문에 큰 어려움 없이 실습을 진행할 수 있었다. 복습을 하면서 빠르게 4장까지 진행했다. 하지만 내가 그동안 기능 구현에 정신을 쏟느라 살펴보지 못했던 개념들이 보이기 시작했다. 이런 것들 면접에 잘 나오겠다. 왜 그동안 이런 당연한 것들에 의문을 가지지 않았을까 등등. 예를 들면, 함수형 컴포넌트와 클래스형 컴포넌트의 차이, 이벤트 종류들, 클래스형에서 constructor의 역할, 이벤트에는 함수 형태의 객체를 전달한다는 사실 등이다. 언젠가 한번 이런 것들을 모아서 블로깅을 해야겠다고 생각했다.

📝 배운 내용 정리

리액트 컴포넌트, props, state 이벤트 핸들링 등

(블로깅을 하게 되면 여기에 링크를 첨부하겠습니다.)

🔆 학습 감정(아무 말)

• 내 블로그가 TIL 범벅으로 되는 것 같다. 앞으로 TIL은 일주일에 2번만 쓰기로 결정했다. 월화수/목금토일 끊어서 일주일에 2번! 대신 다른 컨텐츠를 블로깅하는데 좀 더 힘을 쓰려고 한다.

💻 오늘 진행한 것

• 이제 TIL만 올리면 오늘 일과 끝. 리액트 공부는 하지 못했다.
• DID 실습, VC, VP에 대한 개념 공부 나에게 VC는 스타트업 투자자가 다였었는데, 새로운 VC의 개념이 추가가 되었다. 검증가능한 크레덴셜이라는 뜻의 VC는 디지털 세계에서도 신분증 같이 개인의 신원을 증명할 목적으로 만들어진 개념이다.

  

• 코플릿 40번 문제 - 레퍼런스 이해 완료 어제 TIL에 올렸다시피, 내가 반복적으로 푸는 방법을 탈피하고 싶어 레퍼런스를 유심히 봤다. naive 방식은 이해가 어렵지 않았으나 advanced는 이해하는데 꽤 시간이 소요되었다. 이걸 어떻게 생각해내? 라는 의문이 드는, 매우 어려운 풀이법이였지만, 체화하려고 노력하려고 한다. 표를 쓰는 방식, 모든 경우의 수들을 비교해 최대값을 구하지 말고, 최대값을 기준으로 모든 경우의 수를 비교하는 방식 등을 캐치했다. 다음에 비슷한 유형의 문제가 나왔을 때는 꼭 풀고 싶다.

🔆 학습 감정(아무 말)

• 오늘도 여전히 피곤하다. 아침에 잠을 충분히 자도 전혀 개운하지가 않다. ㅠ
• 내일은 휴일이다! 내일은 리액트 공부를 해볼 생각이다.

DID (Decentralized Identity, 탈중앙 신원증명)

• 데이터 주권이 개개인에게 있고, 필요한 때 그 데이터를 중앙화된 시스템을 거치지 않고 증명할 수 있는 기술
• 분산원장기술(DLT)을 기반으로 한다.
• 중앙화된 레지스트리(데이터 저장소), 데이터 제공자(Provider), 인증기관(Certificate Authorities) 들을 분리하고, 탈중앙화 방식으로 동작할 수 있도록 설계되었다.
• 자기 자신이 신원증명에 대한 권한을 갖도록 하겠다는 SSI 개념을 현실화하기 위해 사용.

DID의 등장 배경

• 웹 생태계에 대해 논의하는 W3C(World Wide Web Consortium)에서 사용자 데이터가 플랫폼(페이스북, 구글 등) 기업에게 종속되는 현상에 대해 문제제기.

• 팀 버너스리(WEB창시)를 주축으로 W3C 참여자와 탈중앙 운동을 전개함.

• 2016년 블록체인 활용 의견 개진, 2019년 DID 문서 표준화 시작.

DID를 위해 필요한 것

1. 데이터 연동을 위한 표준화 - 플랫폼이 독점적으로 데이터를 보유하게 된 것은 타 서비스와 연동이 불가능하기 때문, 탈중앙 생태계를 위해서라면 서비스 간의 데이터 연동이 가장 중요함.
2. 데이터 무결성 및 보안성 확보 - 중앙화되지 않은 저장소에 개인의 신원을 증명할 수 있는 데이터를 보관하면서, 데이터의 무결성과 보안성을 확보하는 것 → 블록체인 기술 등장!

W3C표준화 - DIDs (탈중앙화 식별자)

우리가 흔히 사용하는 ID, Password

• Identity(식별자)

  개인 혹은 단체(법인) 등을 구별할 수 있는 고유 값

• DID 문서

  특정 DID를 어떻게 사용하는지에 대해 설명해 놓은 문서

  • id: 해당 did문서를 설명하고 있는 아이디
  • 공개키: id와 관련된 공개키 리스트
  • 인증정보: id의 소유권을 증명하기 위한 정보
  • 서비스: id와 상호작용이 가능한 서비스들 리스트

• DID 메소드

  특정 분산 원장 또는 네트워크에서 DID 문서들을 생성, 읽기, 갱신, 비활성화를 하는 메커니즘

• DID 형식

  • DID : 이 주소가 did스키마에 따른 것임을 나타냄. 항상 did로 시작
  • example : did 메소드의 이름
  • 123456789abcdefghi : DID 메소드 안에서 사용되는 고유 아이디

• DIF(Decentralized Identity Foundation) 글로벌 조직
  • 전 세계 사용자들이 DID를 보다 쉽게 사용할 수 있도록 지원하기 위해 만든 조직.
  • 사용자 편의성, DID 표준 제작, 소프트웨어 제작 등의 중요한 역할을 맡음.
  • Sovrin, uport, Civic, MS, IBM, Master Card 등이 있음.
• DID 인증 절차
  • 회사에서 DID소유권자에게 DID의 유무를 확인하기 위해 소유권자에게 challenge 신청
  • 소유자인 나는 회사에게 response를 줌
  • 회사는 응답받은 DID로 Universal Resolver에서 DID document를 가져옴.
  • DID document 안에 기록되어 있는 인증정보로 소유자에게 받았던 response를 검사하여 확인.
  • response 검사를 통해 응답한 소유자가 DID를 가지고 있는 것인지 확인.

SSI (Self Sovereignty Identity, 자기 주권 신원)

• 자신이 스스로 부여한 신원, 신원의 소유권을 가진 주체가, 신원에 대한 권리를 갖고, 공개 대상과 범위를 선택할 수 있는 개념
• DID는 SSI의 개념을 블록체인 기술을 기반으로 현실화 함.

신원관리 모델의 종류

• 1세대 : 개별 신원 모델

  개별 서비스마다 이용자의 아이디와 패스워드를 저장하고 신원확인 서비스를 제공하는 형태

  단점 - 서비스별 보안 수준에 따라 신원의 대량 유출 가능성 높음, 이요자는 서비스별 통일되지 않은 ID와 패스워드 정책으로 관리가 어려움.

• 2세대 : 연합형 신원 모델

  중앙화된 연결 서비스 제공자(구글, 카카오, 페이스북)가 신원확인 서비스(OpenID, Oauth)를 제공하는 모델.

  단점 - 글로벌 기업의 개인정보 독점, 사용자 개인정보의 권리 주장 어려움, 유출 위험성 존재

• 3세대 : SSI 모델

  1) 개인이 개인정보 발급 내역을 블록체인에 기록, 개인정보가 필요할 때 발급자(Issuer)에게 2)신원증명정보(DID)를 주고, 3)신원정보(VC)를 받아, 4)검증자(verifier)에게 신원정보를 공유할 수 있는 모델

  장점 - 신원의 가용성과 무결성이 높음 (분산 관리되기 때문에)

  단점 - 비밀번호를 잃어버렸을 경우 다시 찾기 어려움, 초기 설정 어려움

SSI 형성을 위한 3가지 요소

1. DID (Decentralized Identifier)
2. DID Auth (DID Authentication) : 아이디 소유자가 개인키를 가지고 있다는 것을 인증하는 방법
3. DKMS(Decentralized Key Management System, 탈중앙 키관리 시스템) : 신원을 증명하는데 사용하는 개인키를 어떻게 관리할 것인가
4. Verifiable Credentials (검증가능한 크레덴셜) : 아이디의 소유자가 어떤 것을 할 수 있는 자격을 갖추었음을 검증하는 방법.

SSI를 구성하기 위한 요소

1. Issuer : 발행자
2. Holder : 자격증명 소유자
3. Verifier : 자격증명 검증자
4. Verifiable data Registry : 블록체인 등 분산저장소

검증가능한 크레덴셜(VC)이란?

• Credential : 신원 확인에 필요한 정보 (예: 주민등록, 운전면허, 여권)
• W3C Verifiable Credential Data Model: 디지털 세계에서도 민증처럼 신원과 자격을 증명하기 위해 나온 표준
• 즉, VC는 디지털 세계에서의 크리덴셜을 물리적 세계의 신분증과 동일한 정보를 제공하기 위한 목적으로 등장.

구성요소

• Credential Metadata: Credential을 해석할 수 있도록 설명해주는 메타데이터
• 클레임(Claim): 디지털 환경에서의 신원 정보, 각 단위 데이터를 클레임이라고 함. 주체-속성, 값의 구조를 가짐.
• Proofs: Credential을 검증하도록 만드는 암호학적 요소들이 포함된 증명 (전자서명)

VC는 발급자 검증을 위해 4가지를 확인함.

• Issuer DID인지 진위여부
• Holder DID인지 진위여부
• 블록체인의 발급내역 유효, 무효 여부
• 스키마 확인을 통해 형식이 맞는지 확인

검증가능한 프레젠테이션(VP)이란?

최소한의 정보 공개(Minimum Disclosure)를 원칙으로 하여 증명이 필요한 정보들만 구성된 새로운 형식

구성요소

• Presentation Metadata
• Verifiable Credentials
• Proofs

검증가능한 크리덴셜 생태계란? (Ecosystem of Verifiable)

백신접종증명 시나리오 절차

1. 개인은 질병관리청에 본인의 백신접종정보를 요청함.
2. 질병관리청은 요청정보를 확인하고 문제가 없다고 판단되면 Digital Signature(전자서명) 후 개인에게 백신접종증명서를 발행함.
3. 이 때, 질병관리청의 DID정보가 백신접종증명서에 함께 저장됨.
4. 개인은 증명서를 모바일에 보관하며, 다중이용시설 이용 시 전자서명하여 제출함.
5. 다중이용시설은 개인과 질병관리청의 DID를 통해 블록체인에 저장되어 있는 검증정보를 전달받아 백신접종증명서의 접종정보를 확인함.

(확실치 않음. 일반 DID 기술 플로우에 백신접종증명 사례를 대입해본 것임.)

💻 오늘 진행한 것

• DID를 활용한 dApp 개발 DID와 SSI의 개념을 배웠다. 실생활에 가장 접목하기 쉽고 빠르게 적용 중인 블록체인 기술이라고 생각한다. 배우는 내내 내가 겪었던 혹은 간접적으로 접했던 일련의 사건들이 생각났다. 몇 달 전에 한 쇼핑몰에서 내 개인정보가 유출되었다고, 사과의 메일을 받았다. 나는 아무런 피해 보상도 받지 못했는데, 사과 후 아무일 없는 듯이 뻔뻔하게 자신들의 영업을 지속해나가는 해당 쇼핑몰을 볼 때마다 화가 났었다. (엘리베이터 탈 때마다 매일 그 쇼핑몰 광고가 나온다.) 사실 탈중앙화에 대한 필요성을 크게 느껴오지 못했는데, 해당 사건을 내가 직접 겪음으로써 데이터 주권의 중요성을 절실히 깨닫게 되었다. 그리고 이 사건과 연결되는 핵심 기술인 DID를 배우면서, 이 기술이 현재 사회에 얼마나 많이 필요한 지를 느꼈다.

• 코플릿 39번, 40번 문제 - 해결 못 함 39번은 너무 어려웠다. 접근 방법 조차 생각이 나지 않았다. 여태껏 아무리 어려워도 접근 방법은 항상 떠올랐는데 이번 건 떠오르지 않아 절망적이었다. 40번은 기능 자체는 구현 완료했지만 효율적인 코드를 구현하지 못했다. 이 문제는 최대값을 구하는 문제였다. 내가 최대, 최소값을 구하는 방식이 매번 똑같은데 사실 이런식으로 풀어서 한번도 효율적인 코드를 구현해본 적이 없었다. 이 방식을 바꿔야 하는데 어떻게 바꿔야 할 지 몰라서 항상 같은 방식으로 해결해왔다. 이번에는 레퍼런스를 참고해서 방식에 변화를 꼭 주어야겠다고 다짐했다.

📝 배운 내용 정리

탈중앙화 신원 증명 DID

🔆 학습 감정(아무 말)

• 너무 피곤하다. 몸에 피로가 없는 날이 없다. 오늘 페어를 함께 한 민우님께서 약국에서 파트타임을 하시는데 아르기닌을 추천해 주셨다. 아르기닌을 한번 복용해봐야 겠다.
• 오늘 BEB 4기의 얼굴인 민우님과 드디어 페어가 되었다. 거의 3-4시간 동안 잡담만 나눈 거 같다. 민우님 워낙 열심히 하시고 아시는 것도 많은 분이라, 잡담 또한 매우 유익했던 시간이었다. 민우님 학습 방법을 들으면서 굉장히 배울 점도 많았고, 자극도 많이 되었다.
• 민우님이 밋업도 추천해주셨다. 개발자 밋업을 예전부터 많이 가보고 싶었는데, 그 전까지는 나 자신의 정체성을 개발자로 정의하지 않았기 때문에 내가 감히 갈 수 있을까 싶었다. 지금도 물론 나를 개발자라고 말하기 살짝 부끄럽지만, 이제는 나를 이런 환경에 더 노출시켜야겠다는 생각이 들어 신청했다.
• 민우님은 7월부터 진행될 프로젝트3를 준비하고 계신다. 민우님도 포지션을 프론트엔드로 생각하고 계신다. 나는 사실 프로젝트3가 막연히 부담스럽기는 하지만, 아무런 대비를 하고 있지 않았다. 그래서 내가 하고 싶은 스위프트 공부를 하려고 계획했었는데, 안되겠다. 나도 프론트엔드 포지션 준비를 위해 리액트 공부를 해놔야겠다.

😀 솔리디티 기본 문법 정리 KMOOC 내의 포항공대 '스마트 계약 및 응용' 강의 중 솔리디티 기본 문법 내용을 정리해보았다. 일부 내용은 urclass에서 참조했다.

솔리디티 언어

• 절차적 프로그래밍 언어 (함수형 언어와 대비됨), (C++, 자바스크립트, 자바)
• 정적 타입 언어 (like JAVA) : 컴파일 시에 타입이 결정, 오류가 있다면 컴파일 에러가 발생함.
• 객체 지향 언어
• 확장자로 sol을 사용.

SPDX License Identifier

스마트 컨트랙트에 대한 신뢰를 높이고, 저작권 문제를 해소하기 위해 코드 최상단에 SPDX 라이센스를 주석으로 명시. SPDX 라이센스 리스트 // SPDX-License-Identifier: MIT

Pragma

컴파일러의 특정 기능을 활성화 하는 데 사용됨.

1. Version Pragma: 컴파일러 버전 설정 시 사용 caret(^): 해당 메이저 버전의 최신 버전까지 지원한다.
2. ** Experimental Pragma**: 컴파일러나 프로그래밍 언어의 특정 기능 사용 시

import

다른 솔리디티 파일에 있는 코드를 사용할 수 있게 해줌 → 코드의 모듈화가 가능해짐

Contract

• 객체 지향 언어에서의 class와 유사
• Contract 내부 variable에 데이터를 보관하며 이를 제어하기 위한 function들을 가짐.
• 하나의 솔리디티 파일에 여러 contract가 선언될 수 있음.
• Contract 구성: 상태 변수(state variable), 함수(function), 이벤트(event), 함수 제어자(function modifier) 등

상태 변수(State Variables)

Contract 내부에서 선언된 변수 중 function 외부에서 선언된 변수

contract storage에 저장됨. → 모든 function이 접근 가능, function이 변경한 값은 계속해서 저장됨.

Storage: 블록체인에 기록되어 영구적으로 값이 유지되는 데이터 영역 Memory: 프로그램이 동작되는 동안에만 값을 기억하고, 종료되면 값을 잃는 데이터 영역. 대체로 임시값들이 저장됨. (예: function 내에서만 쓰는 파라미터 등)

값형 데이터 타입 (Value types)

• Boolean true(default)/false

• 정수(int, uint) signed integers: 부호 있음 unsigned integer: 부호 없음 8bit ~ 256bit까지 지원 (예: int8: -128 ~ 127, uint16: ~65,535)

• Byte 데이터를 바이너리 형태로 저장하기 위해 byte타입을 지원함. bytes1 ~ bytes32까지 정해져 있음. 크기가 정해져 있기 때문에 fixed-sized byte array라고도 불림. 정해진 바이트 크기와 다르면 에러가 남.

  cf.) bytes 타입: dynamically sized byte array - 참조형(reference) 타입임

• 주소(Address) 20byte 크기의 이더리움 어드레스 balance property를 갖고 있어 이더 잔액을 확인할 수 있음. 이더를 옮기는 transfer, send 메소드 지원(address.transfer(amount), address.send(amount))

• 열거형 (Enumerations) 내부적으로는 정수 값으로 구현됨.

참조형 데이터 타입 (Reference types)

Reference 타입은 EVM 내에서 Storage, Memory 중에서 어디에도 저장될 수 있기 때문에, 어디에 저장할 것인지 명시해야 한다. (data location) 데이터를 저장하는 영역에 연속되어 저장되어 있는 값의** 첫 번째 메모리의 주소를 값**으로 가지는 변수 타입.

• 배열(Arrays) 동일한 타입의 여러 항목을 저장할 때 사용 Fixed Array: 배열 선언 시 크기가 결정됨 ** Dynamic Array**: 실행 중에 크기가 결정됨 2차원 배열 시 다른 언어의 순서와 반대임 (예: array[1][2] → array[2][1])

• 문자열(String) Array의 특별한 형태, bytes array에 기반한 string 타입 Array와 달리 index, push, length, concat 등을 지원하지 않기 때문에 bytes array로 변환해야 함.

• 구조체(Struct) 서로 다른 타입을 하나로 묶어서 사용.

• 매핑(Mappings) key-value pair를 저장할 때 사용되는 데이터 타입. 대부분의 데이터 타입을 key 타입으로 쓸 수 있지만, contract, mapping, struct 타입처럼 복잡한 타입은 key 타입이 될 수 없음. (value로는 사용 가능) storage 영역에만 저장됨. 함수의 parameter나 return type으로 사용될 수 없음. key 값 자체가 mapping에 저장되지 않기 때문에, key의 hash 값을 이용해 value에 접근함.

글로벌 변수

솔리디티에서 현재 이더리움 블록체인 정보(현재 블록정보, 트랜잭션 정보 등)를 제공하는 변수

block

블록 관련 정보를 제공함.

• block.coinbase: 현재 블록을 채굴한 account의 주소를 알려줌
• block.difficulty: 현재 블록 작업 증명의 어려운 정도
• block.gaslimit: 현재 블록이 사용 가능한 최대 gas값
• block.number: 블록 넘버
• block.timestamp: 채굴 시 기록된 시간 정보

msg

컨트랙트는 외부 컨트랙트에서 호출하거나 다른 컨트랙트에서 message call을 하면 실행하는데, 이때 컨트랙트에게 전달된 메시지 정보를 msg object를 통해서 읽을 수 있음.

• msg.sender: contract를 호출한 account의 주소가 들어있음.
• msg.value: 메시지를 통해 전달된 이더가 wei unit으로 담겨있음.
• msg.data: contract로 넘겨진 data가 담겨있음.
• msg.sig: data의 첫 4바이트 → 어떤 메소드가 불리는지 알 수 있음.

tx

트랜잭션 관련 정보를 제공함

• tx.price: 현재 트랜잭션의 gas 비용을 알려줌
• tx.origin: 트랜잭션의 시작 외부소유 어카운트의 address를 알려줌

Address

address 관련 정보를 제공함

• address.balance : 잔고를 보여줌
• address.transfer(amount): 이더를 해당 어드레스로 보냄
• address.send(amount): 이더를 해당 어드레스로 보냄
• address.call(payload)
• address.callcode(payload)
• address.delegatecall()

상태 변수 접근 수준

• internal(default): 선언된 contract와, 해당 contract 로 부터 상속받은 contract에서만 사용할 수 있음.
• private: 선언된 contract에서만 사용 (그럼에도 이더리움 public 블록체인이기 때문에 데이터는 공개되어 있음.)
• public: 외부에서도 접근할 수 있음. 특별히 solidity 컴파일러가 getter 메소드를 생성해 줌.
• constant: 값에 변화가 없음. 처음에 값을 정하지 않거나, 변경을 하려고 하면 에러가 나게 됨.

함수

함수의 구조

• 함수 이름 (Name)

이름으로 함수를 호출할 수 있음. 이름이 없는 함수는 fallback or default function이라고 함.

• 매개변수 (Parameter)

함수에 넘겨질 argument들의 이름과 타입을 선언함.

• 함수 접근 수준 (Visibility)

  • Public: 다른 contract나 외부 계정에서 불릴 수 있음
  • Private: 현재 contract에서만 불릴 수 있음
  • Internal: 자신 외에도 자신으로부터 상속받은 contract로 부터 불릴 수 있음.
  • External: public과 비슷, contract 내로부터 불릴 경우 ‘this’라는 키워드를 붙여야 함.

• Qualifier ( view, pure, payable )

  함수가 contract의 내부 상태(state variable)을 변경할 수 있는 능력 선언, 다른 언어들에서 찾아보기 힘든 개념임.

  • view: storage 내의 variable 읽기O, 변경X
  • pure: storage 내의 variable 읽기X, 변경X
  • payable: 결제를 처리할 수 있다는 선언. 만약 선언되지 않은 함수에 이더를 보내면 거부됨.

• returns

반환하는 타입 선언

• 생성자 함수(constructor)

• selfdestruct

함수 변경자(Modifier)

• 비슷한 역할을 하는 코드를 모아서 만든 특별한 형태의 함수
• 함수처럼 parameter를 받을 수 있고, 바디에 특정 조건을 만족하는지를 확인하는 코드가 들어감.
• underscore(_;) 로 표현된 placeholder에 modifier가 적용된 함수의 코드가 위치함.
• modifier 적용을 위해 적용을 원하는 function의 선언에 modifier의 이름을 추가하면 됨.

에러 핸들링

• Require: 주어진 조건을 검사해서 이를 만족시키지 못하면 exception을 발생시켜 이전 상태로 되돌림. gas 반환 O
• Revert: Require와 유사, control flow가 복잡할 때 (예: 중첩 if) 편리
• Assert: 어떤 값을 변경하고 나서 그 값이 조건을 만족하는지, 절대로 발생하면 안되는 상황인지를 검사. gas 반환 X

주로 require, revert는 함수 앞쪽에서 pre-condition을 확인하는데 사용, assert는 뒷부분에서 post-conditon을 확인하는데 사용

상속

상속을 통해 두 컨트랙트 간에 parent-child relation을 만들어 줌. parent 컨트랙트에서 선언한 함수와 상태 변수들을 child 컨트랙트에서도 사용할 수 있게 해줌. “is” 키워드를 이용해 상속. 다중 상속(multiple inheritance)도 가능. 이때 parent contract 나열 순서가 중요. 가장 뒤에 명명된 컨트랙트가 더 가까운 parent임.

생성자 함수(constructor)

생성자 함수 선언 시, 컨트랙트가 생성될 때 생성자 함수가 실행되며 컨트랙트 상태를 초기화 함.

selfdestruct: 현재 컨트랙트를 소멸시킴. 남은 이더를 주어진 address로 보냄.

selfdestruct(컨트랙트 생성자의 주소);

이벤트

• contract가 작업을 수행하는 동안 로그를 남길 수 있게 해주는 기능.

• contract의 메소드가 불렸는지, contract의 내부의 값이 어떻게 변했는지 등을 알 수 있어 디버깅이 수월함.

• 블록체인 밖의 시스템과의 연동을 가능하게 함.

• 트랜잭션이 끝난 후 → 트랜잭션의 결과가 담긴 ‘Transaction Receipt’가 만들어짐

• Transaction 이후의 상태

• 사용된 총 gas

• Transaction 동안 생성된 log → 블록체인에 기록됨. contract의 상태가 변경되었다는 것을 외부에 알려줄 수도 있음. 바로 이 log를 생성하는데 event가 사용됨.

contract coinTransfer {

    // event 선언: 이벤트명(파라미터유형1 파라미터1, 파라미터유형2 파라미터2, ...);
    // variable의 이름을 명시할 필요는 없음. (타입만 나열해도 ok)
    // indexed라고 명시해서 선언 -> hash table에 저장되어 나중에 event를 쉽게 찾을 수 있음
    event Transfer(address from, address to, uint256 value);

    function transfer(address to, address amount) {

        // event가 'emit'을 통해 불려짐, 값들이 블록체인에 저장됨.
        // emit 이벤트명(인자1, 인자2 ...)
        emit Transfer(msg.sender, to, amount);
    }
}

Library

• 대표적인 예: Openzeppelin
• contract와 유사한 방식으로 선언됨. (contract 키워드 대신 library 키워드 사용)
• contract와 다른점: state variable X, 상속 관계 X, fallback 함수 X, payable 함수 X
• 파라미터를 받을 수 있음.
• Library 호출 방법: 라이브러리 이름.메소드이름(), using 라이브러리 이름 for 데이터타입

• 클레이튼 개발 환경에서 NFT 개발 Klaytn IDE, Kaikas 지갑, baobab 테스트넷, Truffle 등을 이용해 클레이튼 개발 환경에서 NFT를 민팅해보았다. 사실 매뉴얼대로 하기만 하면 됐어서 크게 어려운 건 없었으나, 중간 중간 과거에 작성된 매뉴얼과는 다른 현재 환경으로 인해 작은 오류들이 많이 발생했다. 그래도 나는 이런 것들을 좀 잘 해결하는 편인 것 같다. 이번에 실습을 함께한 페어분과 소통하면서 이런 오류들을 나서서 해결해드렸다.

• 솔리디티 문법 정리 지난 주부터 하던 솔리디티 문법 정리를 마무리했다. 그동안 실습하랴 알고리즘 푸랴 시간이 없었는데, 오늘 실습이 좀 빠르게 마무리 되어 정리할 시간이 드디어 생겼다! 머리에 다 들어온 것은 아니고, 자유자재로 활용할 수 있는 것은 더더욱 아니지만, 개념이 잘 정리된 것 같다. 솔리디티 문법 정리

• 알고리즘 2문제 - 다 풀었다 오늘은 알고리즘 2문제(오늘꺼, 어제꺼)를 풀어버림으로써 뿌듯함 할당량을 다 채울 수 있을 정도로 기분 좋은 시작이었다. 처음에 재귀를 접했을 때 너무나도 어려워서 항상 피했었는데, 알고리즘을 잘 풀려면 재귀를 잘 활용해야 한다는 것을 알고 부딪히기로 했고, 요며칠 재귀로 알고리즘 문제를 해결해보면서 어느 정도 재귀를 자유자재로 쓸 수 있게 된 것 같다. 이렇게 성장하는구나를 느끼며 매우 뿌듯했다. coinChange 코드 decompression 코드

⬇️ 이틀이 걸린 코드가 성공한 순간

📝 배운 내용 정리

• KIP-17 이더리움의 ERC-721과 같은 내용을 담고 있는 클레이튼의 NFT 인터페이스 ERC-721에는 identity를 검증하는 ERC-165가 있었다면,KIP-17에서는 KIP-13으로 Identity를 검증함.

  Klaytn IDE에서는 한 페이지에서 코드를 구현한다. Full Code

🔆 학습 감정(아무 말)

• 최근에 알고리즘에 흥미와 자신감이 붙으면서 이를 좀 더 확대해보자(?) 싶어서 현대모비스 알고리즘 경연대회를 접수했다. 물론 전국 알고리즘 고인물들이 몰릴 것 같지만 그래두 코딩테스트 대비할 겸 알고리즘 공부에 좀 더 불을 지펴볼 겸 신청을 했다! 7월 1일까지 잊혀진 자바랑 C언어를 다시 되새겨야겠다.
• 주말에 공부할 시간이 부족할 듯 싶다. 이번 주말에 동기 분들이랑 함께 하루종일 놀기로 했기 때문이다. 그래! 놀땐 놀아야지~~ 이번주 솔직히 좀 열공했다ㅋ 담주도 이번주 만큼만이라두!!
• 오늘 아침 운동🏊 후 계속 공부만 했다. 카페 체류 시간은 10시간이 넘는다. (민폐 손님) 그런데도 많은 것을 한 것 같지 않은 기분. 시간이 너무 빨리 지나간다.😭

💻 오늘 진행한 것

• ERC721 NFT를 생성할 수 있는 표준인 ERC-721에 대해 학습하고, 실습을 진행했다.

• 알고리즘 36번 문제 - 아직 푸는 중 오늘 문제야 말로 수능 30번 문제를 똑 빼닮았다. 왕년에 수학 3,6월 모고 만점자로서 꼭 풀어보겠다는 다짐과 함께 시작했다. 복잡하긴 했지만 패턴을 찾아낼 수 있었고, 재귀를 통해 문제를 해결할 수 있을 것 같았다. 하지만 코드로 구현이 상당히 까다로워서 아직 다 하지 못했다. 내일 또는 이번 주 안으로 이어서 진행할 예정이다. ▼ 풀었던 흔적

📝 배운 내용 정리

ERC-721

• NFT를 생성할 수 있는 표준
• 대표적인 함수: balanceof, ownerOf, approve, getApproved, setApprovalForAll
• 민팅이란? 민팅은 디지털 자산에 고유한 일련번호를 각인하는 개념으로 어떤 상품에든 고유한 가치를 부여하는 것.
• Openzeppelin 라이브러리에 민팅 기능이 없다. 그래서 민팅 기능의 코드를 추가해 주어야 한다.

🔆 학습 감정(아무 말)

• 어제 새벽 4시 넘어 잠드는 바람에 오늘을 늦게 시작했다. 근데 밤에 좀 더 집중이 잘 되는 편인 거 같다.
• 내일은 꼭 운동을 가야지. 그래서 지금 컴터 끄면 바로 잘 생각이다.
• 알고리즘 너무 풀고 싶은데, 시간은 시간대로 잡아먹고, 풀리진 않으니 아무런 성과가 없는 기분이여서 짜증이 났다.
• 오늘도 집공을 했는데 하루종일 헤롱헤롱 댔다. 역시 집공은 나랑 안 맞아. 내일은 카공이다!!