traders_free custom_top_html:no
default debug random = 1 / type = READ / detected = READ

어제 잠깐 이더리움의 옐로페이퍼를 보았다.

https://docs.google.com/viewer?url=http://gavwood.com/Paper.pdf

 

논문이고, 익숙하지 않은 부호들이 있어서, 처음에는 읽기가 좀 어려웠지만,

그래도 건성으로 듬성듬성 읽어보니, 아주 좋은 자료였다.

 

그런데, 이 자료를 읽어보면서, 의문이 생겼다.

(물론 구체적인 기술을 본인이 모르니 아래의 얘기가 다소 공상적일 수는 있다.)

 

먼저, 서버-클라이언트의 인터넷을 보자, 

만약 도스, 디도스 공격이 발생을 하면 이를 막는 수단은 서버 측에서 이들 공격을 판단하여 이들을 선택적으로 차단하는 방법이 있다. 

또한 서버의 계산능력이 충분하다면 도스, 디도스 공격을 막을 수 있을 것이다. 

 

예로 평균적으로 서버의 계산능력의 절반만 사용하는 서버 시스템을 갖추고 있다면, 도스, 디도스 공격이 여유분의 계산능력으로 대응이 가능하다면, 이런 공격은 효과가 없을 것이다. 하지만, 이것을 비용부담이 크다.

 

하지만, 요즘은 클라우드를 사용한다면, 서버의 계산 능력을 능동적으로 조절할 수 있기 때문에 대부분의 도스, 디도스 공격을 방어할 수 있는 것 같다.

 

------

이제 이더리움을 생각해보자..

이더리움은 자체 네트워크를 보호하기 위해서 개스비를 요구하고 있다.

이는 인터넷 (서버-클라이언트) 시스템에는 없는 기능이다.

 

어제 이더리움의 실행코드를 실행할 때 꼭 개스비가 필요할까라는 생각을 해보았다.

물론 개스비가 필요한 이유는 도스, 디도스 공격에서 자체 네트워크를 보호하기 위해서이다.

 

그렇다면, 보는 점을 달리해서, 이더리움을 보자.

노드 하나가 꼭 블럭체인의 전체를 만들어야 할 이유가 있을까?

물론 비트코인의 블럭체인을 이더리움이 이어받았기 때문에 이런 것이 유지되는 것일 수 있다.

 

즉, 다수의 노드가 블럭을 생성할 노드를 합의하여 매번 다른 하나의 노드가 블럭을 생성하고, 이때 컨트랙트는 다수의 노드가 나누어서 계산을 하고 이를 블럭을 생성하는 노드에게 전달해주는 방법도 생각해볼 수 있다.

 

이것의 원리는 도스 공격에서 서버의 계산 능력이 부족하면, 서버의 계산 능력을 늘려주면 도스 공격을 무력화 할 수 있는 원리와 같다.

 

이더리움에서 아무리 많은 컨트렉트가 동시에 실행이 되더라도, 수많은 노드들이 서로 계산을 나누어 계산을 한다면, 도스 공격에 대한 방어를 할 수 있을 것이다.

물론 채굴과 관계가 있기 때문에, 이더의 가격이 낮으면, 적은 노드가 채굴을 하고, 그러면 도스 공격에 취약할 수는 있다..

 

컨트랙트 실행하다가 개스비가 모자라면 out of gas가 발생을 하고, 처음의 상태로 되돌리는 것을 보고 개스비라는 것이 네트워크에 좋은 점도 나쁜 점도 있다고 생각했다.

 

물론 미래에는 컨트렉트를 실행하기 전에 도스, 디도스 공격을 파악하여 개스비를 누진적, 또는 차등적으로 부과함으로서, 이런 공격을 누그러트릴 수는 있을 것이다.

 

하지만, 현재 인터넷을 사용하는 것 자체는 무료이므로, 이더리움 네트워크를 사용하는 것 자체에 게스비를 부과하는 것은 일종의 문턱 역할을 하는 것이 아닌가를 생각을 해보았다.

 

 

-------

 

합의 알고리즘을 만들 때 꼭 노드들이 경쟁을 할 필요는 없죠.

서로 일을 분담하고, 서로 검증하면서 하는 방법이 이더리움의 컨트랙트를 다룰 때 더 유리할 수도 있습니다.

8

loum님의 서명

 

 
 
 
댓글 10
  • ?
    "이더리움에서 아무리 많은 컨트렉트가 동시에 실행이 되더라도, 수많은 노드들이 서로 계산을 나누어 계산을 한다면, 도스 공격에 대한 방어를 할 수 있을 것이다."
    - '다른 노드에 의해 계산된 값을 신뢰할 수 있는가'에 대한 문제가 발생되기에 불가능하다고 생각됩니다.
  • ?
    @Memo

    그냥 스치는 생각입니다.

     

    다른 노드가 한 것은 모두 검증을 통과해야 하겠죠...

    구체적인 구현 방법은 아주 다양할 것으로 보입니다.


    핵심은 한 노드가 블럭을 만드는 것이 아니라,
    노드들이 협력하여 블럭을 조금씩 나누어서 만드는 시스템에 대한 아이디어입니다.

    이것이 더 합리적이고, 이성적인 접근 방법으로 보이기는 합니다.

    실용성은 모르겠고  아이디어는 괜찮아 보입니다..

  • 그래서, 공개는 안 하였지만, 제가 고려하는 블록체인에서는 Trusted Super Node 를 만들 기준을 정하고 있습니다.
    @loum 님의 생각이 더 정당하다 봅니다.
    어느정도의 신뢰기반의 독립 권위있는 서버가 다수 존재하는게 적절한 보완방법 이라 봅니다.
  • ?
    @안씨아저씨
    감사합니다.
  • "모든 노드가 똑같은 일을 하지 말고 나눠서 분담하자, 그래야 네트워크가 지속적으로 스케일링할 수 있지 않을까?"
    이런 관점이 바로 sharding 이 이루고자 하는 내용입니다.
    이더리움 2.0 스펙을 좀 더 자세히 연구해보심을 추천합니다.
    http://vitalik.ca/files/mauve_paper.html

     

    Sharding

    Now, we consider expanding from one shard to multiple shards. We construct a model as follows. Instead of having one single blockchain, we now have multiple interrelated chains, which we call "shards". There are NUM_SHARDSshards, numbered shard 0 to shard NUM_SHARDS - 1, where shard 0 simply operates as a regular proof-of-stake blockchain with finality as above, but shards 1 ... NUM_SHARDS - 1 work differently. At the start of every epoch, a random VALIDATORS_PER_SHARD validators are selected for each shard, and are assigned as validators for that shard for the next epoch (ie. the validators for epoch n+1 are assigned at the start of epoch n). getValidator(skips), when called to determine the validator within one of these shards, simply picks randomly (with an even distribution, as the deposit-size weighting was already done at selection time) from one of the selected validators. The "finality" bets for shards 1 ... NUM_SHARDS - 1 are not made inside the shards; rather, they are made in shard 0. When a bet is made, it is stored, and the bet is evaluated only after the end of the subsequent epoch (ie. finality claims for blocks during epoch n+1are evaluated in shard 0 at the start of epoch n+3).

     



    Diagonal lines represent required cross-shard communication

     

    If a validator has been selected for a shard, that validator will need to call the registerForShard(bytes32 vchash, uint256 shard, uint256 index, bytes32 randao) function of the Casper contract, where vchash is the validator's validation code hash, shard is the shard ID, index is a value where 0 <= index < VALIDATORS_PER_SHARD where getShardValidator(uint256 shard, uint256 index) returns the given validation code hash, and randao is a randao commitment. This function generates a receipt that can then be confirmed on the target shard using confirmReceipt(uint256 receiptId) in order to induct the validator.

    getShardValidator is itself a function with similar logic to getValidator, though it relies on a separate source of randomness. This source of randomness is derived as follows:

    1. During each epoch, for 0 <= k < 24, keep track of the number of times that the kth last bit of the globalRandao is equal to 1 minus the number of times that the kth bit is equal to 0.
    2. At the end of each epoch, let combinedRandao be the value such that for each 0 <= k < 24, the kth bit is equal to 1 if during that block there were more 1s in the globalRandao's during that epoch and 0 otherwise. Bits above the 24th are all zero. Use sha3(combinedRandao) as the source of randomness.

    This uses Iddo Bentov's low-influence functions to increase the cost of exploitation for this source of randomness, as this particular random seed has substantial economic consequence and will thus be a greater-than-normal target for exploitation.

    Cross-shard finality bets are NOT in the block header, so as not to overly bog down light clients; instead, the validator is expected to create a transaction calling a registerFinalityBets(bytes32[] hashes, bytes logodds) function during any block that they create that expects NUM_SHARDS hashes and a byte array NUM_SHARDS bytes long with each byte representing odds for the corresponding block hash.

    The typical workflow for a validator would be to maintain a "full node" for shard 0, and also keep track of which future shards they will be assigned to. If a validator is assigned to a shard, they would download the state using Merkle tree proofs and make sure that they have the state downloaded when they need to start validating. For that epoch, they would act as a validator for that shard and make blocks; at the same time, they would make finality bets on all shards, where they would infer what to bet on by looking at (i) what the longest chain is on each shard, (ii) other validators' finality bets, and (iii) various secondary heuristics and mechanisms that try to catch successful 51% attacks within a shard (eg. fraud proofs). Note that the probability of being assigned to any given shard is proportional to the validator's deposited ether; hence, a validator that is twice as rich would have to do twice as much computation. This property is considered desirable, as it increases fairness and reduces pooling incentives, and introduces an element where processing transactions and storing the blockchain itself becomes a form of "hybrid proof of work".

    The intention of the sampling mechanism is to ensure that the system is secure against even attackers that have up to ~33-40% of the total deposited ether (less than 50% because an attacker with 33-50% of deposits may "get lucky" on some given shard), while only relying on a few validators to actually verify transactions; because the sampling is random, attackers cannot choose to concentrate their stake power on a single shard, a fatal flaw of many proof-of-work sharding schemes. Even if a shard does get attacked, there is a second line of defense: if the other validators see evidence of an attack, then they can refuse to make finality claims that follow the attacker's forks, instead confirming the chain that appears to be created by honest nodes. If an attacker on a shard tries to create a chain out of invalid blocks, validators of other shards can detect this, and then temporarily become fully validating nodes on that shard, and make sure that they are only finalizing valid blocks.

  • ?
    @atomrigs

    정보 감사합니다.
    읽어보겠습니다.

     

    위 글을 쓰고, 생각했던 것이 

    pow의 경우 계산과 검증의 비대칭성을 이용합니다.

    즉, 계산은 아주 오래 걸리고, 검증은 바로 쉽게 계산하죠.. 

     

    "노드가 일을 나누어서 하면, 일을 나누어서 하는 것하고, 이를 검증하는 것 사이의 시간 차이는 어떻게 될까?"라는 생각도 해보았습니다.

     

    물론, 검증시간이 너무 오래걸리면, 노드 하나가 블럭을 처리하는 것이 좋겠죠..

    샤딩으로 보니, 일을 나누어서 하는 것에도 비 대칭성이 존재하는 것 같습니다.

     

  • 원래 shard 개념은 bigdata 에서 나왔어요. 그 이전에는 P2P engine 의 블록 나눠서 여기 저기 나눠 놓는것에서 나왔죠.

    처리하는 것을 조각조각 분리해서 저장하고, 이를 읽어와서 합치는것이죠.

    Hadoop 이나 mongodb , 하둡의 원조인 Google 의 BigTable 등에서 DB 의 데이터를 어떻게 분산 저장하고, Integrity 를 보장할 실질적 방법이 뭔지에 대해서 고민한 산출물입니다. 그래서, 같은 shard 를 여러개 (최소 3개이상) 하여 저장하죠.
    왜? 3개 냐구요?
    BigData 적인 통계관점에서 나온 현실적인 Magic Number 라고 보시면 됩니다.

    더 근본적으로 올라가면, torrent 같이 , P2P 파일의 저장과 이의 검증,(checksum/md5/sha256) 을 이용한 확인.

    BigChain 이나, IPFS 같은경우도 이를 나눠서 저장하는것이죠.

    이것이, 블록체인의 Proof 에 접목되어서는 BFT (Byzantine Fault Tolerent) 같은 개념을 만족, 위의 @loum 님 얘기대로, 일은 나누되, 일정한 난이도를 가지게 하는것, 검증은 체크섬만 확인해서, 전체의 검증 시간이 일정한 범주 (너무 빠르지도, 너무 늦지도않고 일정한 범위내) Proof 를 가능하게 좀더 넣은 것이죠.

    그래서, 이를 표현하는데, 기본적인 개념은 shard 의 그 틀안에서 D(ivided) PoW 또는 D(ivided) PoS 같은 개념으로 보면 됩니다.
    NOT Delegated 입니다!!

    이때, 어떻게 할 일에 대해서 일정한 시간으로 Load Balancing 이 가능할까 인데,
    현실적으로 정확한 답이나, 이를 제대로 만족할 방법은 아직 없습니다.

    아직은 제대로 PoW 나 , PoS 자체도 제가 보기에는 검증 알고리즘의 랜덤성 (솔로 채굴을 해보시면 그 분산이 엄청 랜덤합니다.)
    으로 인해서, Linear (scalable) 하지는 않기 때문에,
    아직은 개념입니다.

    그래서, Delegated Proof 를 쓰는 전용 검증 노드가 더욱 현실적인 상황이라 판단하기에, Trusted Super Node 를 활용하는것이 더 좋다 봅니다.
  • ?
    @안씨아저씨
    소중한 정보 감사합니다.
  • @안씨아저씨
    좋은 내용이네요 감사합니다 ^^
  • ?
    @안씨아저씨

    저도 Trusted Super Node를 사용하는 것 여러 가지로 편하고, 쉬운 방법으로 생각합니다.
    이런 노드가 있으면, 비잔틴 장군 문제, 51% 공격 등에 대해서 대응하기가 무척 편합니다.

    저도 개인적으로는 이런 방향으로 변화할 가능성이 높다고 생각하고 있습니다.

    하지만, p2p 선호론자들의 입장에서 보면, 분산화가 안되었다고 공격을 하지 않은까라는 걱정은 합니다.

     

    합의 알고리즘에 대해서도, 많이 생각을 하셨네요..

    포스가 느껴집니다.


List of Articles
번호 제목 추천 수 조회 수 글쓴이 날짜
공지 땡글 경매 4탄!! APPLE 아이패드 프로 1세대 9.7 WiFi 32GB + 1세대 APPLE Pencil 3 newfile 7 199
ESN경매
2019.11.22
공지 가칭 "땡글 지갑" 베타테스터를 모집합니다. 24 updatefile 12 636
땡글개발자
2019.11.15
공지 로그인이 안되시는 분은 문의해주시기 바랍니다. 4 5 2439
땡글개발자
2019.08.21
5618 이더리움이 화폐단위를 사용하는 이유, 이더리움을 보유해서 좋은 이유 *** 답변 댓글이 있을 때 글 내용 삭제시 경고 없이 계정이 정지됩니다. *** *** 개인정보가 포함된 경우 혹은 불법적인 요소의 수정은 가능합니다.*** -----------------------------------------------------------... 2 0 2659
eshnl
2017.03.12
5617 바이트볼 좀 설명해주실분 계신가요? *** 답변 댓글이 있을 때 글 내용 삭제시 경고 없이 계정이 정지됩니다. *** *** 개인정보가 포함된 경우 혹은 불법적인 요소의 수정은 가능합니다.*** -----------------------------------------------------------... 8 0 3330
kasrin
2017.03.11
5616 DASH가 고공행진을 하는 특별한 대쉬만의 강점이 있는건지요? *** 답변 댓글이 있을 때 글 내용 삭제시 경고 없이 계정이 정지됩니다. *** *** 개인정보가 포함된 경우 혹은 불법적인 요소의 수정은 가능합니다.*** -----------------------------------------------------------... 5 file 0 3164
gogogo
2017.03.11
5615 내일 바이트볼 3차 배포 입니다. *** 답변 댓글이 있을 때 글 내용 삭제시 경고 없이 계정이 정지됩니다. *** *** 개인정보가 포함된 경우 혹은 불법적인 요소의 수정은 가능합니다.*** -----------------------------------------------------------... 0 2222
호오라
2017.03.11
5614 채굴속도와 메모리 에러 요번에는 채굴자를 위한 팁을 하나 소개합니다.   RX470 이나 RX480 을 사용하시는 분들은 기본적으로 램 타이밍값을 바꾸고, 코어클럭은 언더클럭하고 메모리는 오버클럭을 하는 경우가 매우 일반적입니다. 그렇게 ... 8 file 12 5827
atomrigs
2017.03.11
5613 이더리움 난이도 폭탄 업데이트 이더리움 난이도 폭탄과 PoS 로의 전환일정 등에 대해 관심이 많을텐데요, 최근 비탈릭이 이에 대한 입장을 이야기했습니다. 자세한 내용은 체인톡에서 확인할 수 있습니다.   http://www.chaintalk.io/bbs/board.php... 7 4 4475
atomrigs
2017.03.10
5612 3월 2주차 가상화폐 관련 뉴스입니다.    제 기준으로 눈에 띄는 뉴스들만 정리해보았습니다. 잘못된 뉴스나 다른 이슈거리가 있다면 보충,지적해주시면 감사하겠습니다. :) 코인 트레이딩에 많은 도움 되셨으면 좋겠습니다.   NEWS 비트코인(BTC) SegWit... 3 file 8 2724
진상손님
2017.03.09
5611 이더리움pos로의 전환은 pow의 끝을 의미합니다. *** 답변 댓글이 있을 때 글 내용 삭제시 경고 없이 계정이 정지됩니다. *** *** 개인정보가 포함된 경우 혹은 불법적인 요소의 수정은 가능합니다.*** -----------------------------------------------------------... 11 0 5552
헬로카봇
2017.03.09
5610 코모도 바이트볼 골렘 코인보유중인데 좋은소식좀없나요? 갈수록 바닥만가네요 ㅠ 프리세일때 못사서 등재되자마자 샀더니 계속 떨어지네요 ㅠ 1 0 3526
건우애비
2017.03.09
5609 코인 종류별로 지갑은 따로 만들어야 하나요? 안녕하세요    현재는 비트코인만 소량으로 채굴하고 있습니다.   비트코인 지갑은 블록체인에다가 만들어서 저장하고 있습니다.   조만간 baikal miner를 구매해서 dash를 채굴하려고 하는대 dash를 보관하기 위해서... 2 0 2364
sk8kim
2017.03.08
5608 이더리움 mainnet접속 *** 답변 댓글이 있을 때 글 내용 삭제시 경고 없이 계정이 정지됩니다. *** *** 개인정보가 포함된 경우 혹은 불법적인 요소의 수정은 가능합니다.*** -----------------------------------------------------------... 0 1048
헬로카봇
2017.03.08
5607 G Coin 이라고 다들 아십니까? *** 답변 댓글이 있을 때 글 내용 삭제시 경고 없이 계정이 정지됩니다. *** *** 개인정보가 포함된 경우 혹은 불법적인 요소의 수정은 가능합니다.*** -----------------------------------------------------------... 1 0 2379
devilx03
2017.03.08
5606 안녕하세요 이중결제 질문좀 드립니다. *** 답변 댓글이 있을 때 글 내용 삭제시 경고 없이 계정이 정지됩니다. *** *** 개인정보가 포함된 경우 혹은 불법적인 요소의 수정은 가능합니다.*** -----------------------------------------------------------... 0 824
호이호이
2017.03.08
5605 비트코인 거래 과정 질문드립니다 *** 답변 댓글이 있을 때 글 내용 삭제시 경고 없이 계정이 정지됩니다. *** *** 개인정보가 포함된 경우 혹은 불법적인 요소의 수정은 가능합니다.*** -----------------------------------------------------------... 4 0 1098
이문세
2017.03.07
5604 해외에서 비트코인 현금화 하는 방법부탁드립니다. 해외에서 비트코인 현금화 하는 방법부탁드립니다. 해외에 있는데 비트코인을 현금화하는데 무리가좀있네요.. 해외거래소에서 하려고 해도인증절차가 무슨 세금을 낸이력? 이런게 있어야한다고 하고,,  한국에 안간지... 3 0 3053
떙떙이야
2017.03.07
5603 미연준의 블록체인과 페이먼트 시스템에 대한 입장 미국 연준의 블록체인과 페이먼트 시스템과 관련한 입장을 엿볼 수 있는 연설이 있어서 소개합니다. http://www.chaintalk.io/bbs/board.php?bo_table=study&amp;wr_id=202   연준의 블록체인/분산원장기술에 대한 연... 3 4 1809
atomrigs
2017.03.07
5602 거래소 관련 문의 *** 답변 댓글이 있을 때 글 내용 삭제시 경고 없이 계정이 정지됩니다. *** *** 개인정보가 포함된 경우 혹은 불법적인 요소의 수정은 가능합니다.*** -----------------------------------------------------------... 5 0 1770
묭묭
2017.03.07
5601 coinomi 지갑에 대해서 자문 구합니다. *** 답변 댓글이 있을 때 글 내용 삭제시 경고 없이 계정이 정지됩니다. *** *** 개인정보가 포함된 경우 혹은 불법적인 요소의 수정은 가능합니다.*** -----------------------------------------------------------... 0 1601
대군림
2017.03.06
5600 아주 단순한 질문 하나 드립니다. *** 답변 댓글이 있을 때 글 내용 삭제시 경고 없이 계정이 정지됩니다. *** *** 개인정보가 포함된 경우 혹은 불법적인 요소의 수정은 가능합니다.*** -----------------------------------------------------------... 6 0 2649
브리티시젠틀맨
2017.03.06
5599 해외 송금 관련 해서 조언 부탁 드립니다. *** 답변 댓글이 있을 때 글 내용 삭제시 경고 없이 계정이 정지됩니다. *** *** 개인정보가 포함된 경우 혹은 불법적인 요소의 수정은 가능합니다.*** -----------------------------------------------------------... 8 0 2004
오잉2
2017.03.06
목록
Board Pagination Prev 1 ... 752 753 754 755 756 757 758 759 760 761 ... 1037 Next
/ 1037
PC debug / slots = 2 / size = 0 / random = 1