비대칭 키 시스템에서는 지식은 증명가능하나 프라이버시가 노출됨 ① 정우성이 자신의 공개키를 공개하고 '나는 정우성이다' 라는 메세지를 개인키로 잠궈서 인터넷상에 뿌렸을 때 정우성의 공개키로 열린다면 그 메세지는 정우성이 작성한 것이 증명됨 ② 프라이버시가 공개(정우성의 공개키) ===A. zero knowledge proof === 영지식증명: 어떤 statement가

왜 "Encrypted Data" 인가?? DNA profile match Medical predictions Spam detection Face recognition Financial prediction 사전지식: Homomorphic encryption (동형이체암호화) 동형이체: 같은 형태를 가진 다른 몸체 특성: 암호화된 상태에서 연산한

안녕하세요, 이더리움 코드보는 sigmoid입니다. 이 글을 계기로 비트코인류의 코드를 처음으로 접하게 되네요. 얼마전 인터넷 게시판을 눈팅하던중, 논란이 있는 어떤 코인을 보게되었습니다. 이 글에서는 해당 프로젝트의 문제여부를 판단하고자 하는 것이 아니라는 점 다시한번 명확하게 밝힙니다. 마스터 노드기반의 다크 코인인데, 실제 메인넷에 staking까지 모두

몇몇 코인들의 등장을 시간순으로 정렬해보았습니다. (개인적으로 좋아하는 코인 위주로 정리를 하고 있었는데, 지인께서 coinmarketcap에서 낸 "50 coins"라는 책을 알려주셨고, 오늘 딱 도착했기에 일부 인덱스를 참조하였습니다) 이렇게 시간순으로 정리해두면, 왜 이때 이런 코인들이 생겼으며, 앞으로는 어떤 코인들이 생겨날것인지에

지갑앱을 만들경우 가장 먼저 해야하는 계정생성이라 새로운 계정을 생성하는 flow를 간략하게 정리해봅니다. RPC등을 통해 요청된 ethapi의 NewAccount함수가 사용자가 입력한 암호와 함께 호출된다 프라이빗 키와 퍼블릭키를 Elliptic Curve Digital Signature Algorithm (타원곡선 디지털 서명 알고리즘)으로 생성한다 생성된

류기혁님의 자료를 바탕으로 코인을 만들어 보았습니다. 참조: 그리고 계약코드를 간단하게 분석해보았습니다. (휴가중이라, 수기로....) 최종 코인을 만드는데 사용된(상속된) 컨트렉트는 총 4가지 입니다. 작성자가(ownable) 여러명에게 전송하는 기능(multi-transfer) 작성자가(ownable) 자신의 보유잔고의 일부를 삭제함으로서, 토큰의 총량을

안녕하세요 이더리움 주석을 한글로 번역하고 있는 sigmoid 입니다. p2p 패키지의 주석을 번역하다 보니, 어느 정도 큰그림을 잡고 분석해지 않으면 코드보다가 산으로 갈것 같다는 느낌이 들어서 간단하게 정리를 해보게 되었습니다. 나타나는 단어들만 정리해봐도 이 정도거든요. 네트워크 프로토콜: TCP/UDP/NAT/SNTP p2p: kademlia like

안녕하세요, 오늘은 blockchain 패키지의 insertChain 함수를 조금 정리해 보고자 합니다. 예전 몇몇 글을 통해 블록을 체인에 넣을때 트렌젝션 처리와 상태의 변화가 일어나는것을 알아보았었고, 담당하는 함수가 insertChain이라는것도 이미 알고 있었죠. ( 참조) 그럼에도 불구하고 또 이 글을 쓰게된 이유는, 오늘 쌩뚱맞게도 과연 EVM이란

현재 나의 상태다. 최소한 내PC에서는 1개 혹은 2개의 블록차이가 영영 유지될 수 밖에 없다는 결론. 예전에 싱크 코드를 분석한적이 있었다. ( 간단하게 요약하자면 "pivot"포인트를 잡아서 pivot-fsMinFullBlocks까지는 fast mode로 외부에서 블록/영수증을 받고, 이후부터는 full 검증모드로 내가 직접 블록을 처리하여

오늘은 eth패키지와 core패키지를 분석해보았습니다. 이 두 패키지는 아래 그림처럼 뗄래야 뗄수 없는 관계네요. 몇몇 구조체를 정리해본것인데요, eth패키지에 해당하는 Ethereum, LesServer, Protocol매니져와 core패키지에 해당하는 TxPool과 blockchain구조체가 그림과 같이 서로 얽혀있습니다. 블록체인에 합의엔진/ 처리자 /

지난번 만들었던, 간단한 ML데이터로 논스를 예측하도록 geth를 수정했습니다. 트레이닝된 모델을 파일로 저장하고, 입력 파라미터로 난이도를 주는 형태의 파이썬 파일을 하나 만들고 ethash쪽의 sealer 쪽에 제 이름을 딴 get_sigmoid함수를 만들고 난이도값을 전달하는거죠 우선 실행을 해보니 뭔가 값이 나오긴합니다만, 이상한 현상이 발견됩니다.

오늘은 core/types폴더에 있는 types패키지를 분석해보았습니다. types 패키지는 "이더리움 합의와 관련된 데이터 타입을 정의한다" 라고 되어있습니다. 어찌보면, 우리가 이더리움을 이해하기 위해서 가장 기본이 되는 용어(terminology)라고 볼수 있겠죠. 선언된 타입들의 연관관계는 그림과 같습니다. 몇개의 특징 필드에 대해서

매일 패키지를 하나씩 분석하는게 개인적인 목표였는데, 잠깐 머리도 식힐겸 오늘은 조금 다른 것을 해보았습니다. 문득 이런 생각이 들더라고요 " 어차피 seed가 랜덤이고 1씩 증가시키며 해싱한 값을 블록 난이도 조건에 만족하는지 확인하는 건데, 1씩 증가시키는게 과연 효율적인가? 뭔가 의미있는 값을 넣어보면 더 좋지 않을까?" "블록

오늘은 state패키지를 알아보고자 합니다. state 패키지는 코어 패키지의 내부에 구현이 되어있는데, 주석을 읽어 보면 "이더리움 상태 트라이의 최상위 캐싱 레이어" 라고 되어있습니다. (나름 코어!) 무슨말인지 모르겠으니 하나하나 살펴보도록 하겠습니다. 먼저 상태(state)에 대해 간략하게 짚고 넘어가 보겠습니다. "이더리움은

consensus package는 개념상으로 합의엔진을 정의하고 구현하는데, 엔진으로서 구현해야하는 기능은 다음과 같습니다. 헤더 검증 블록 난이도의 검증: 부모+타임스템프 블록넘버: 부모+1 인장 검증: 논스 검증 가스 사용량 DAO, fork처리 엉클 검증: 엉클블록에 대한 처리(7세대까지만 허용하는 부분) 인장(seal) 검증: 블록이 난이도 조건을 만족하는지

패키지 설명에는 "높은수준의 이더리움 계정 관리를 구현한다"고 되어있습니다. 우선 어카운트 매니져가 어떻게 어카운트에 접근하는지를 먼저 이해해야 할것 같습니다. 그림과 같이 어카운트 매니져는 크게 2가지의 백엔드를 통해 정보를 얻어내도록 되어있습니다. 키스토어 파일 USB 허브 이 각각의 백엔드들은 자신들이 가진 지갑(들)의 정보를 가지고

이미 많은 글들을 통해 이더리움이 머클 패트리샤 트리를 사용하는 것을 다들 아실 것입니다. 간단히 요약하자면 블록의 헤더를 구성하는 3개의 머클 패트리샤 트리의 루트 해시( 상태루트, 트렌젝션루트, 영수증 루트)로 헤더만으로도 블록이 위조되었는지 검증이 가능하다 정도일것입니다. 오늘은 머클 패트리샤 트리를 어떻게 생성하고 관리하는지 알아보려고 합니다. 우선

안녕하세요 이더리움 한글 주석 프로젝트를 진행하면서 READEME의 패키지 인덱스 부분은 따로 공유하는 것이 좋을것 같아 이렇게 글을 남깁니다. geth개발에 사용된 패키지들의 위치와 간단한 설명을 추가해두었습니다. Packages or binaries. Accounts: 계정과 키스토어, 계약계정, 지갑관련 기능 package accounts:높은 수준의

Geth노드를 분석해 보면, 결국 아래와 같은 블록 다이어그램으로 표현할수 있을 것 같습니다. 우선 geth는 이더리움 서비스 및 그 외 통계적 서비스, 그리고 지갑(어카운트 매니져), 마이닝, p2p 노드 역할을 수행합니다. 그래서 geth는 지갑이자, 노드입니다. 이더리움은 geth 노드에서 동작하는 이더리움 프로토콜과 이더리움 서비스들의 모임입니다. 말이

Go Ethereum - Korean 안녕하세요, 이더리움 한글 주석 프로젝트 진행상황을 공유합니다. v0.2현재 126개 파일에 약 1000줄의 주석이 한글로 변환되었습니다. 앞으로의 진행방향은, 각 패키지/ 혹은 폴더별로 이더리움 네트워크에서 담당하는 부분을 명확하게 정리 자체 제작중인 이더리움 맵에 맞추어 패키지/파일 위치 배치하기 입니다. 혼자서 하는