나도 dApp 개발해보자 (1) - 시리즈를 시작하며 > 연재 강좌

체인톡 (ChainTalk.io) - 이더리움 커뮤니티

서울이더리움 밋업 - Loom Network…
블록체인 소개자료4
암호화폐 비판에 대한 반론
dapp 개발 예제로 배우기 사이트 (한글)42

1  Ico  and  이더리움  블록체인  Dapp  비트코인  or 

 

연재 강좌

나도 dApp 개발 | 나도 dApp 개발해보자 (1) - 시리즈를 시작하며

페이지 정보

작성자 atomrigs 쪽지보내기 프로필 아이디로 검색 전체게시물  (24.♡.140.♡) 작성일17-03-12 02:50 조회36,560회 댓글38건

본문


 

 

 

이더리움은 

 

기존의 비트코인처럼

  

이더 자체를

달러나 원화와 같은 화폐를

대체하기 위한

 

 

새로운 지불수단으로서의

기능을 구현하려고

만들어진 것이 아닙니다.

 

 

물론 이더리움도 비트코인처럼

지불수단으로서의 기능도

훌륭히 수행할 수 있고,

 

 

비트코인과 비교하면

처리용량, 속도, 옵션 추가 등의 면에서

더 발전된 형태의 수단입니다.

 

 

 

하지만 이더리움의 진정한 가치는

단순한 지불 수단의 의미를 넘어서서,

매우 다양한 스마트 컨트랙트와

이를 바탕으로 한 탈중앙화된 어플리케이션 (dApp)

만들 수 있는 플랫폼이라는 점에 있습니다.

 

 

 

2008년 비트코인의 등장 이후

비트코인의 단점을 해결하기 위한

정말 무수히 많은 카피코인들이

많이 나왔었습니다.

 

 

 

이 가운데는 지불 수단 이외의

여러 가지 특수한 기능들을

구현해보기 위한 시도들도 많았습니다.

 

 

 

하지만 대부분의 이러한 시도는

어떤 특정한 문제 하나를

해결하기 위한

단순한 시도들이었습니다.

좀 더 철학적 용어로

자기완결적인 시도들이다

이렇게 이야기합니다.

외부로의 확장성이 적다는거죠.

그 안에서만 놀고 끝낸다 이런 이야기.

 

 

 

, 별도의 독자적인 블록체인을 만들고,

필요한 기능을 구현하기 위한 코드들을

전부 자체적으로 다 구축하는 방식이었습니다.

그 블록체인을 유지하기 위한

인프라(채굴, 합의시스템 등)

별도로 구축해야 했습니다.

대충 듣기만 해도 좀 비효율적이다

이런 생각이 들겝니다.

 

 

 

이러한 독립적인 체인과 시스템이

유리한 경우도 분명히 있습니다.

 

 

하지만,

많은 경우에 충분한 리소스가 없는 상태에서

안정적으로 이러한 시스템을 개발, 유지, 확대하는 것은

무척 어려운 일입니다.

 

 

몇 년간 수도 없이 많은 코인들이

나타났다가 쉽게 사라지는 것이

바로 이 이유 때문입니다.

 

 

또한 이렇게 만들어진 여러 블록체인/코인 들 간에

상호운용성이 결여 되어 있다보니,

서로 시너지 효과를 살리지 못하고

단절되어 독자적인 생태계를 확보해야하는

어려움에 직면하게 됩니다.

 

 

이더리움은

이러한 블록체인 개발 환경을

보다 통합적이고 상호유기적으로

발전시킬 수 있도록,

 

 

여러 어플리케이션의 공통분모를

플랫폼으로 만들어 버리고자 한 것입니다.

특수한 기능을 구현하기 위해,

별도의 체인을 다시 만들 필요 없이,

공통의 이더리움 체인을 기반으로 해서,

공통의 개발환경과 개발언어를 사용해서

보다 효율적으로 어플리케이션을

만들 수 있게 하자는 것이지요.

 

비탈릭이 이더리움이 무엇인지를

설명하는 프리젠테이션에 항상 등장하는 그림이 있는데,

이더리움의 장점과 특징을 잘 설명하고 있다고 봅니다.

 

 

단일 기능에 특화되어 있는 기존의 솔루션들은

이런 계산기와 같습니다.

한 가지 기능만을 잘 수행하기 위해 만들어져 있습니다.

 

 

 

조금 더 발전된 형태는 이 정도입니다.

 

 

이들 툴에 비교하자면 이더리움은 스마트 폰과 같습니다.

 

 

 

 

, 이더리움은 특정한 기능 몇 가지를

구현하기 위해서 만들어진 어플리케이션이 아니라,

온갖 종류의 다양한 탈중앙화된 어플리케이션(dApp)

만들 수 있도록 해주는 베이스 플랫폼입니다.

 

 

 

범용 플랫폼이다 보니,

이더리움 시스템의 개발에는

더 많은 노력과 시간이 필요한 것은

사실입니다.

 

 

 

새로 윈도우즈나 리눅스를 만든다고

생각해보시면 되십니다.

대단히 규모가 큰 프로젝트인거죠.

 

 

전체 블록체인 사이즈 스케일링도

매우 중요한 이슈가 됩니다.

많은 어플리케이션들의 로직과 데이터를

다 담아야 되니까

 

 

체인의 부피도 커지고

효율적인 속도를 유지하는 것도

매우 어려운 과제가 됩니다.

 

 

 

하지만 좋은 아이디어가 있어서

이를 블록체인을 이용해

구현해보려는

많은 개발자들에게는

너무나 반가운 시스템이

아닐 수 없습니다.

 

 

체인 자체를 개발하고 운영해야 하는

모든 수고를 다 들어주기 때문입니다.

구현하려고 하는 비지니스 로직자체에

촛점을 맞추면 되기 때문입니다.

 

 

 

비유를 하자면 기존 웹사이트 하나를 만들기 위해서

아파치 웹서버 자체를 본인이 다 코딩해서 만들어야 된다고 한다면,

사이트 하나 만들기 위해 얼마나 많은 시간과 노력이 들어갈까요?

 

 

아파치 서버를 잘 쓰기 위한

기본적인 지식과 셋팅 노하우만 있으면

아파치 서버 내부의 로직을 정확히 알지 못해도

웹 사이트 를 만드는 과정에 별 장애가 안됩니다.

이더리움 플랫폼이 블록체인을 기반으로

한 어플리케이션 개발에 얼마나 중요한 역할을

할지 알 수 있는 하나의 대목입니다.

 

 

 

제가 아직 미흡한 수준임에도 불구하고,

dApp 개발 시리즈를 시작할 수 있게 한 것도

바로 이러한 이더리움 플랫폼이 가진 장점 때문입니다.

 

 

dApp을 돌아가게 하는 모든 내부 메카니즘과 코드를

일일히 다 들추어서 보여주지 않더라도,

dApp의 기본적인 구성과 작동 메카니즘을

보여줄 수 있기 때문입니다.

 

 

그만큼 dApp 개발에 참여할 수 있는 문턱이

낮아졌다는 것을 의미합니다.

 

 

물론 아직 이더리움이 완성단계가 아니기 때문에,

보안과 여러 가지 성능 향상을 위해서는

내부 메카니즘에 대한

보다 세부적인 이해가 절대적으로 필요한 경우도 있고

많은 도움이 될 때도 있습니다.

 

 

한글로 된 dApp개발 강좌나 문서가

너무나 부재한 상태에서

저의 이 시리즈가 dApp 에 대한

한국 개발자들의 관심을 불러일으키고,

처음으로 dApp에 입문하는 사람들에게

조금이라도 도움이 되었으면 하는 바램입니다.

 

 

설사 dApp 개발에 직접 참여하지 않더라도,

이더리움에 관심이 있는 분이라면,

한번 쯤 배워보는 것도 나쁘지 않다고 봅니다.

이더리움에 대한 심층적인 이해에 많은 도움이 될 것입니다.

 

 

다음 편에서는

기존의 중앙서버 시스템과 dApp 의 아키텍처 비교를 통해

dApp이 이슈가 되는지,

또 그 기본적인 구조는 어떠한지를

알아보도록 하겠습니다.

 

 

 

나도 dApp 개발해보자 (2) - dApp의 아키텍쳐

나도 dApp 개발해보자 (3) - 스마트 컨트랙트 맛보기


나도 dApp 개발해보자 (4) - 컨트랙트 엑세스


 

[이 게시물은 CHAINTALK님에 의해 2017-03-18 16:55:18 정보 자료에서 이동 됨]

  • 페이스북으로 보내기
  • 트위터로 보내기
  • 구글플러스로 보내기
추천 24 비추천 0

atomrigs 쪽지보내기 프로필 아이디로 검색 전체게시물 11,489TALK 2d19FDE5B4Cac4e1AfA54ee749C368C68c18316c

여보슈! 당신의 살림살이도 비참한 모양인데 지금 가는 곳이 어디시우? 쓸데없이 돌아다니지 말고 우리 적당으로 들어와 한 몫 보는게 어떻겠소? (역사 속의 야담 - 풍류열전)

댓글목록

밸리데이터님의 댓글

밸리데이터 쪽지보내기 프로필 아이디로 검색 전체게시물 아이피 118.♡.79.♡ 작성일

코인의 옥석을 가리는 눈을 맹글어 주신 아톰님께서 우리를 디엡 개발자로 변신시켜 주시겠는데요 ㅎㅎㅎ

loum님의 댓글

loum 쪽지보내기 프로필 아이디로 검색 전체게시물 아이피 85.♡.9.♡ 작성일

좋은 정보를 알려주셔서 항상 감사합니다.

이더리움에 대해서 떠오른 생각을 적습니다. (이더리움에 대해 잘은 모름)
비트코인의 제한된 명령어(opcode)를 가진 튜링 불완전 스크립트를 가진 반면,
이더리움은 이런 빈틈을 파고들어 튜링 완전한 스크립트를 제공하며, 이를 위한 EVM 및 high level 언어를 제공합니다.
 이런 점은 방향성도 휼륭하고 올바른 방향인 것은 모든 사람들이 동의를 할 수 있을 것입니다.

하지만, 현재의 이더리움이 인터넷과 같은 역할을 하기에는 문제가 있다고 생각합니다. (발전은 하겠죠..)
1) 보안을 위해 개스값을 지불하고 컨트랙트를 실행하는 구조입니다.
이를 위해서 유저가 컨트랙트 실행을 위한 최대 지불한 개스를 gaslimit로 설정하는 방법을 사용합니다.
제 눈에는 이런 방법이 좀 어설픈 것 같은 느낌입니다.

네트워크 보안을 위해서, 제가 보기에는 사토시는 비트코인에 일부러, 작정하고 loop명령어를 제거했습니다.
(이는 네트워크를 보호할 목적입니다. 만일 스크립트로 무한 루프를 돌리는 경우를 대비한 의도적으로 스크립트를 튜링 불완전하게 만든 것으로 보입니다.)

하지만, 비테린은 튜링 완전 언어를 위해서, 개스를 도입하고, gaslimit를 사용합니다. (네트워크 보안을 위해 개스를 도입하는 것입니다.)
이 부분이 저에게는 좀 어설퍼 보이는 부분입니다.

따라서 개인적으로 이를 개선할 새로운 방법이 있을 것으로 보이며, 따라서, 새로운 경쟁자가 나올 수 있을 것으로 봅니다.
이더리움이 뉴링 완전 스크립트로 기선제압은 했지만, 아직은 더 발전하거나 gas를 대체한 새로운 방법이 나올 수도 있다고 봅니다.

그외에 스트립트인 코드를 저장하고, 중간값 및 결과값을 저장하기 위한 storage가 필수적으로 필요하고, 이를 블럭체인에 포함하여야 일관성을 유지합니다.
(코드 및 storage가 블럭체인에 반드시 포함되어야 논리적인데요.. 이 부분의 확인은 안되었습니다. 헤더해시만 포함된 것으로 읽기는 했는데 더 확인해보야 합니다.)
이런 코드 및 저장공간(storage)는 많은 저장공간을 필요로 합니다.
이를 해결하기 위해서 이더리움은 분산 DB 형태의 샤딩 방법을 사용하려 합니다.
하지만, 유저가 많아지고, 사용량이 크게 증가하면, 코드 및 저장 공간 또한 증가하는 구조입니다.
이런 구조를 완화하려면, 사용하지 않는 코드 및 저장 공간을 삭제하는 알고리즘이 추가로 필요한데..
이에 대한 대비는 아직 하지 않고, 샤딩으로 피하는 방법을 적용하고 노력하고 있는 것으로 보입니다.

물론 샤딩이 끝나면, 이런 삭제 알고리즘이 추가될 수도 있습니다.
또한 이런 삭제 알고리즘이 가능한지도 잘 모르겠습니다. 물론 하드포크를 해서 이런 기능을 추가할 수 있을 듯은 보입니다.

아톰님이 정보를 제공해 주시는 데 정말 감사하고 있습니다.
이더리움에 대해서 잘은 모르지만 제가 가지고 있던 궁금증이기도 합니다.
단지, 제 궁금증이지, 이더리움에 대한 비평은 아닙니다.. 아직까지 그 정도로 파악이 안되었습니다.
그냥 기술적인 궁금증입니다.

atomrigs님의 댓글

atomrigs 쪽지보내기 프로필 아이디로 검색 전체게시물 아이피 24.♡.140.♡ 작성일

우선 긴 코멘트 감사드립니다.
(1) 이더리움의 코어 시스템 로직 자체를 다루려는 것은 조금 피해보려고 했는데, 언급을 해주시니 피해갈 수가 없네요 ㅋㅋ
무한루프와 같은 EVM 을 어뷰징하는 것을 방지하기 위한 수단으로 개스를 사용한 것은 맞습니다. 하지만 논리적으로 이를 근본적으로 대체할만한 수단이 쉽게 나올 것 같지는 않습니다. 기본적으로 컨트랙트를 실행하기 위한 컴퓨팅 리소스를 사용했으므로 그에 대한 비용이 발생하고, 이를 누군가가 지불해야 된다는 점에서 개스 컨셉 자체가 어설픈 논리라고 생각하지는 않습니다. 자원 사용에 대한 비용의 개념이 잘못되었다고 보지는 않습니다. 다만 각 opcodes 마다의 개스값을 어떻게 산정하는 것이 바람직한가에 대해서는 아직 개선의 여지가 남아 있다고 생각합니다. 또한 현재 코드가 실행되기전 사용될 전체의 개스값을 미리 결정하지 못한다는 약점을 어떻게 보안할지에 대해서도 더 연구가 필요해 보입니다.
이 주제에 비탈릭의 의견이 있었습니다.
https://www.reddit.com/r/ethereum/comments/572n4q/on_gas_price_markets/

(2) 말씀하신 스크립트인 코드는 컴파일되어서 트랜잭션을 통해 블럭체인에 기록됩니다. 코드를 가진 어카운트를 컨트랙트라고 부릅니다. 컨트렉트에는 코드 뿐만 아니라 컨트랙트의 여러가지 상태(state) 변수들도 유지합니다. 반면 유저의 프라이빗키를 통해 통제하는 어카운트를 외부소유 어카운트 (EOA) 라고 부릅니다. 보통 떠올리게 되는 사용자 어카운트가 이에 해당합니다. 이들 어카운트의 생성과 상태변화는 트랜잭션을 통해 변하게 됩니다.
그런데 막상 체인에서 전파시키는 로우데이타를 보면, 트랜잭션들과, 트리해시값은 보이는데, 해당 블럭 시점의 어카운트 상태 자체 테이블은 보이지 않습니다. 이것을 보고 어카운트 상태가 블록체인에 없다고 생각을 하시는 것 같습니다. 블록체인의 개념정의에 어디까지의 데이타를 블럭체인 "안"에 있는 것으로 정의하는게 따라 달라질 수 있겠지만, 이더리움의 일반적 표현에서는 블럭체인 데이타가 어카운트의 스테이트를 포함하고 있다고 간주합니다.
왜냐 하면 한 시점의 스테이트는 그 이전까지의 모든 트랜잭션의 최종 결과이므로, 그 트랜잭션을 전부 가지고 있다는 것은 결국 최종 스테이트의 값을 가지고 있다는 논리적 등치가 됩니다. 스테이트 테이블이 계속 커지는데, 전체 테이블을 매 블럭마다 전체 네트워크에 다시 전송해야 된다면 효율적인 블록주기 관리는 불가능해질 것입니다. 아무리 네트워크 속도가 빨라진다고 해도, 매 블럭마다  수 기가 나아가서는 수십 기가 이상의 데이타를 전체 네트워크로 전파시킨다는 것은 상상하기 어려운 나쁜 디자인이 될 것입니다.
그렇다면 각 노드가 가지고 있는 최종 스테이트 값이 같다는 것은 어떻게 보장할 수 있을까요?  이것을 위해서는 루트해시값만 비교를 해봐도 보장할 수 있습니다. 각 노드는 매 블럭의 트랜잭션을 처리하면서 전체 어카운트 스테이트 테이블을 디스크와 메모리에 저장합니다. 작년 이더리움에 DoS 공격 동안에 밸런스가 없는 뻥어카운트들이 매우 많이 생겼었습니다. 이것들 때문에 메모리 요구량이 매우 늘어났고, 이것을 인덱스해서 처리해야 되기 때문에, 노드 속도들이 많이 떨어졌었습니다. 채굴풀들이 이걸 처리하는데 시간이 걸리니까, 아예 신규 트랜잭션들을 포함하지 않는 편법들도 등장했었구요.
이 때 이들 뻥어카운트를 삭제하는 문제를 놓고도 논쟁이 일부 있었습니다. 어뷰징에 의해서 생겨났고, 앞으로 절대 사용하지 않게 될 어카운트를 지우는 것 마저도 불편하게 생각하는 사람들이 있었습니다.

(3) 범용 플랫폼의 특성상 스케일링이 매우 크리티컬한 이슈이지요. 샤딩이 말씀처럼 다른 대비는 하지 않고 소극적으로 "피하는 방법"이라고는 생각하지 않지만, 샤딩이외에 데이타를 최대한 경량화하고 효율화시키는 방법이 있다면 이것을 적용하는 것도 중요하다고 생각합니다. 하지만 사용하지 않는 코드와 저장공간을 임의적으로 판단하는게 쉽지는 않을 것으로 봅니다. 오히려 컨트랙트를 올릴 때, 유효기간을 설정하게 하는 방법이 더 현실적이지 않을까, 그리고 그에 따른 비용의 차이를 줘서, 필요없이 오래 저장공간에 남지 않도록 하는 것이 더 현실적인 방법이 될 수도 있을 것 같습니다.

저 역시 미흡한 수준이라 잘못된 정보가 있을 수도 있습니다.
감사합니다.

loum님의 댓글

loum 쪽지보내기 프로필 아이디로 검색 전체게시물 댓글의 댓글 아이피 85.♡.18.♡ 작성일

정성스런 답변 감사합니다.

개스 얘기는 보안 때문에 튜링 완전과 동일한 주제로 보였기 때문이고..
저는 이 개스가 좀 불편하게 보이는 것은 사실입니다.

개스 외에 네트워크 보안을 해결할 수단이 마땅치 않다는 것도 동의합니다.

하지만, '튜링 불완전'에서 '튜링 완전' 스크립트로 갈 때 가장 문제였던 네트워크 보안 문제를 이더리움은 개스로 해결하는 것이 가장 핵심입니다.
이런 점 때문에 튜링 완전 문제의 핵심인 보안 문제의 해법으로 제시한 개스의 개념이 저에게는 좀 부족하게 보입니다.

즉, '튜링 완전'으로 갈때 이더리움측이 가장 신경을 써야할 부분을 개스로 단순하고 쉽게 해결한 것 같은 느낌이 드는 것은 사실입니다.

이는 개스의 특징이 좀 안좋기 때문입니다.
해킹에 사용된 out of gas로 인해서 발생한 롤백, 개스비로 인해서 네트워크를 사용하는데 금전적인 제한에 의한 코딩 길이 등의 제한이 어쩔 수 없이 생기는 점 등입니다.

만일 인터넷에서 네이버, 구글이 처음 생겼을 때 일정한 요금을 청구한다면, 이와 같이 인터넷이 발전하지는 않았을 것입니다.

'유효기간'을 설정하는 아이디어는 상당히 좋은 아이디어입니다. 효과도 상당한 정도 있을 것 같고요..
하지만, 블럭체인에 기록된 기록을 제거하는 문제이기 때문에 구현이 가능한지는 다른 문제가 될 것 같습니다.

휼륭하고, 정성껏 토론에 응해주셔 감사합니다.
항상 많은 것을 배웁니다.

atomrigs님의 댓글

atomrigs 쪽지보내기 프로필 아이디로 검색 전체게시물 댓글의 댓글 아이피 24.♡.140.♡ 작성일

개스가 그렇게 깔끔한 솔루션이 아닌 것은 맞는 것 같습니다. 그러데 인터넷과 비교하자면, 인터넷 사용에 의해 비용이 발생하지 않기 때문에 네이버와 구글이 무료로 서비스를 제공하는 것이 아니라, 발생한 비용을 광고라는 모델로 서비스주체가 이를 흡수했기 때문입니다. TV 에서도 무료서비스가 가능한 것은 광고가 있기 때문에, 방송사의 비용을 충당하고도 남는 이익을 챙기는 것이지요. 광고를 빼면 시청료를 물어야 합니다. 국가가 일괄적으로 세금으로 지불하던, 개별 시청자가 각각 부담을 하던 말이죠.
그렇다면 블록체인을 사용하면서 개스 비용을 이용자에게 전가시키지 않을 수 있을까요?
dApp 모델에 따라서는 프리세일한 토큰을 일부 리저브해서 이를 가지고 비용을 충당하는 방법도 있을 수 있을 수 있겠습니다.
또는 일부 중앙화를 인정한다면, 노드를 유지하고 트랜잭션을 처리하는 주체를 한정하고, 이들에게 신규 코인을 발행해서 노드유지비 이상의 리워드를 주고, 나머지 사용자들의 트랜잭션에는 비용을 징수하지 않을 수도 있습니다. 물론 사용자들이 사용할 수 있는 트랜잭션 양은 시간당 일정하게 제한 당하겠지요. 가지고 있는 밸런스에 바인딩될 수도 있겠구요
또다른 해결방법은 탈중앙화된 광고모델을 도입하는 것인데, 시네로의 attention economy 활용이 대표적인 모델입니다. 시네로의 개발능력으로는 쉽게 구현이 안될 것 같지만, 컨셉자체는 매우 훌륭하다고 봅니다. 네트워크 사용의 모든 주체가 동일하게 비용응 부담하는 것이 아니라, 남에게 광고나 홍보를 해야 할 필요가 있는 사람은 비용을 더 부담하는 것이죠. 역으로 그 메시지가 다른 사람에게 연결될 수 있는 영향력이 있는 사용자는 오히려 돈을 버는 구조가 될 수도 있게 하는 것이죠.

개스를 사용하지 않고도 튜링 완전한 VM 을 사용할 수 있는 모델이 있다면 당연히 더 우월한 모델이겠지요. 그렇지 않다면 타협적인 중간형태의 모델도 있을 수 있겠지만, 그리 깔끔한 모델이 될 것 같지는 않습니다. 그렇다면 네트워크 사용에 대한 비용발생 개념 자체을 받아 들이되, 이 비용을 누구에게 어떻게 물릴 것인가에 대해 좀 더 다양한 모델을 검토해봐야 하지 않을까 싶습니다.
저 역시 많은 것을 다시 생각해보게 되고 배우게 됩니다. 감사합니다.

문D님의 댓글

문D 쪽지보내기 프로필 아이디로 검색 전체게시물 아이피 59.♡.122.♡ 작성일

가입하고 바뻐서 지나치다 이제서야 글을 읽게 됩니다.
좋은글 감사합니다.
기본없이 뛰어든 코인세상이라 더욱 단비 같네요

연재 강좌 목록

Total 146건 1 페이지
연재 강좌 목록
번호 제목 글쓴이 날짜 조회 추천 비추천
146 나도 dApp 개발 판문점선언 이더리움 스마트컨트랙 인기글 atomrigs 쪽지보내기 프로필 아이디로 검색 전체게시물 04-30 1569 3 0
145 블록체인 2.0 블록체인 같이 공부하실분!! 댓글9 인기글관련링크 코인마스터 쪽지보내기 프로필 아이디로 검색 전체게시물 01-29 2687 1 0
144 기타 dapp 개발 예제로 배우기 사이트 (한글) 댓글42 인기글 CHAINTALK 쪽지보내기 프로필 아이디로 검색 전체게시물 01-28 30781 61 1
143 블록체인 2.0 프론트엔드 개발자를 채용합니다. 인기글 스마트헌터 쪽지보내기 프로필 아이디로 검색 전체게시물 01-23 1394 0 0
142 블록체인 2.0 글로벌 블록 체인 인덱스를 올바르게 여는 방법 인기글첨부파일 scryinfo 쪽지보내기 프로필 아이디로 검색 전체게시물 01-08 1189 0 0
141 기타 블락체인을 활용한 인증, 서명 시스템을 구축하실 개발자분을 찾습니다 댓글1 인기글 아이투섹 쪽지보내기 홈페이지 프로필 아이디로 검색 전체게시물 12-30 1857 1 0
140 기타 늑대 컨트렉트 - 스마트 하지 못한 스마트 계약 댓글2 인기글 철학자 쪽지보내기 프로필 아이디로 검색 전체게시물 12-13 3425 2 0
139 기타 블록체인 도입결정을 돕는 플로우차트 인기글 암호화폐당 쪽지보내기 홈페이지 프로필 아이디로 검색 전체게시물 12-07 1769 1 0
138 기타 이더리움 작동원리의 이해(1) 인기글 정주해 쪽지보내기 프로필 아이디로 검색 전체게시물 11-26 3977 1 0
137 로움의 암호화폐 EOS 밋업에 관심과 참여에 감사드립니다. 댓글4 인기글첨부파일 loum 쪽지보내기 프로필 아이디로 검색 전체게시물 09-12 2962 1 0
136 쿤s의 dApp 개발 [쿤s의 dApp 개발][입문 1편] - Metamask 설치 댓글3 인기글 쿤s 쪽지보내기 프로필 아이디로 검색 전체게시물 08-29 5930 1 0
135 기타 Bounty structure 인기글 쿨맨 쪽지보내기 프로필 아이디로 검색 전체게시물 08-16 1450 0 0
134 쿤s의 dApp 개발 [쿤s의 dApp 개발] New Prologue - 솔리디티 & 스마트 컨트랙트 댓글5 인기글 쿤s 쪽지보내기 프로필 아이디로 검색 전체게시물 08-16 23046 6 0
133 로움의 암호화폐 [본인 논문공개] 튜링완전 암호화폐에서 새로운 네트워크 보안 방법 (이더리움의 가스 시… 댓글1 인기글 loum 쪽지보내기 프로필 아이디로 검색 전체게시물 08-14 2879 3 0
132 블록체인 2.0 [Announce] MUSICOIN 지갑을 MyEtherwallet 에 추가하였습니다. 댓글1 인기글 안씨아저씨 쪽지보내기 프로필 아이디로 검색 전체게시물 08-04 3476 3 0
131 기타 5분만에 트러플로 ICO하기 댓글3 인기글 철학자 쪽지보내기 프로필 아이디로 검색 전체게시물 08-04 6524 1 0
130 기타 패러티 멀티시그 지갑 공격 분석자료 인기글 철학자 쪽지보내기 프로필 아이디로 검색 전체게시물 08-04 2244 1 0
129 로움의 암호화폐 이더리움의 EEA에 회사들이 몰리는 이유 인기글 loum 쪽지보내기 프로필 아이디로 검색 전체게시물 07-22 3692 3 0
128 기타 AWS 에 2노드 프라이빗 이더리움 네트웤 구성해보기 인기글 atomrigs 쪽지보내기 프로필 아이디로 검색 전체게시물 07-22 3558 2 0
127 기타 web3.js 1.0 preview 릴리즈 인기글 atomrigs 쪽지보내기 프로필 아이디로 검색 전체게시물 07-22 2692 0 0
게시물 검색