traders_free custom_top_html:no
default debug random = 0 / 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 선호론자들의 입장에서 보면, 분산화가 안되었다고 공격을 하지 않은까라는 걱정은 합니다.

     

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

    포스가 느껴집니다.

default debug random = 0 / type = READ / detected = READ

List of Articles
번호 제목 추천 수 조회 수 글쓴이 날짜
5542 이더리움 네임서비스 (ENS) - 3월 14일 메인넷 론칭 이더리움 지갑주소나 컨트랙트 주소를 서로 보내거나 기억하기가 매우 힘들죠? 인터넷에서 ip 주소 대신 google.com 같은 기억하기 쉬운 이름으로 바꾸어서 사용하듯이 이더리움에서도 헥스주소를 임의의 이름으로 바... 7 file 11 5381
atomrigs
2017.02.18
5541 이더리움 챠트 *** 답변 댓글이 있을 때 글 내용 삭제시 경고 없이 계정이 정지됩니다. *** *** 개인정보가 포함된 경우 혹은 불법적인 요소의 수정은 가능합니다.   ------------------------------------------------------------... 12 file 7 4691
나빌래라
2017.02.18
5540 비탈릭의 cryptoeconomics 소개 비탈릭이 파리에서 진행중인 이더리움 유럽 개발자모임 (EDCON) 에서 발제한 cryptoeconomics 자료입니다.   http://vitalik.ca/files/intro_cryptoeconomics.pdf   비트코인의 PoW 와 이더리움의 PoS 에 대한 재미있... file 8 2657
atomrigs
2017.02.18
5539 Nexium 베타 게임 론칭 임박 이더리움을 사용해 RTS 게임안에서 사용할 수 있는 인게임 토큰인 넥시움을 발행한 프로젝트가 있습니다. 댓글에서 제가 몇번 언급을 했었는데, 다음주에 베타게임이 나오는다는 소식에 가격이 다시 움직이고 있네요.... 6 1 2121
atomrigs
2017.02.17
5538 코인원 홈피 다운 *** 답변 댓글이 있을 때 글 내용 삭제시 경고 없이 계정이 정지됩니다. *** *** 개인정보가 포함된 경우 혹은 불법적인 요소의 수정은 가능합니다.*** -----------------------------------------------------------... 3 0 1076
cacao
2017.02.15
5537 비트코인을 적금 형식으로 맡겨두고 싶습니다 *** 답변 댓글이 있을 때 글 내용 삭제시 경고 없이 계정이 정지됩니다. *** *** 개인정보가 포함된 경우 혹은 불법적인 요소의 수정은 가능합니다.*** -----------------------------------------------------------... 2 0 1561
Oyster
2017.02.14
5536 비트코인 대량구매 *** 답변 댓글이 있을 때 글 내용 삭제시 경고 없이 계정이 정지됩니다. *** *** 개인정보가 포함된 경우 혹은 불법적인 요소의 수정은 가능합니다.*** -----------------------------------------------------------... 8 0 1829
vanvanee
2017.02.14
5535 제트코인 *** 답변 댓글이 있을 때 글 내용 삭제시 경고 없이 계정이 정지됩니다. *** *** 개인정보가 포함된 경우 혹은 불법적인 요소의 수정은 가능합니다.*** -----------------------------------------------------------... 0 1200
오리궁뎅이
2017.02.14
5534 경제학적으로 비트코인을 계속 찍어내도 괜찮은가요? *** 답변 댓글이 있을 때 글 내용 삭제시 경고 없이 계정이 정지됩니다. *** *** 개인정보가 포함된 경우 혹은 불법적인 요소의 수정은 가능합니다.*** -----------------------------------------------------------... 3 0 1074
Vaultboy
2017.02.14
5533 혹시 비트코인 최초의 거래소가 어디인지 아시는 분 계신가요? *** 답변 댓글이 있을 때 글 내용 삭제시 경고 없이 계정이 정지됩니다. *** *** 개인정보가 포함된 경우 혹은 불법적인 요소의 수정은 가능합니다.*** -----------------------------------------------------------... 2 0 801
발컨즈
2017.02.14
5532 엔터프라이즈 이더리움 블럭체인 그룹 이더리움 블럭체인을 사용한 기업용 어플리케이션 개발에 관심을 가진 업체들에 대한 보도들이 이전에도 많이 있었지만, 이번에 보다 본격적인 그룹이 출범했습니다. 주요 참여 회사이름들은 다음과 같습니다.   JP M... 4 13 2645
atomrigs
2017.02.14
5531 지갑관련 궁금한 사항 *** 답변 댓글이 있을 때 글 내용 삭제시 경고 없이 계정이 정지됩니다. *** *** 개인정보가 포함된 경우 혹은 불법적인 요소의 수정은 가능합니다.***     땡글 회원인데 궁금한게 너무 많은 코인 초심자 입니다. 몇... 5 0 709
좋은하루님
2017.02.14
5530 코인원 접속 저만 안되나요 *** 답변 댓글이 있을 때 글 내용 삭제시 경고 없이 계정이 정지됩니다. *** *** 개인정보가 포함된 경우 혹은 불법적인 요소의 수정은 가능합니다.*** -----------------------------------------------------------... 1 0 703
방울이
2017.02.13
5529 폴로닉스 마진거래 잘 아시는 분 계신가요? *** 답변 댓글이 있을 때 글 내용 삭제시 경고 없이 계정이 정지됩니다. *** *** 개인정보가 포함된 경우 혹은 불법적인 요소의 수정은 가능합니다.*** -----------------------------------------------------------... 2 0 4262
카네모치
2017.02.13
5528 이더 패러티 출금 질문... *** 답변 댓글이 있을 때 글 내용 삭제시 경고 없이 계정이 정지됩니다. *** *** 개인정보가 포함된 경우 혹은 불법적인 요소의 수정은 가능합니다.*** -----------------------------------------------------------... 2 file 0 592
skanEorl
2017.02.13
5527 폴로닉스 레벨2단계인데요 *** 답변 댓글이 있을 때 글 내용 삭제시 경고 없이 계정이 정지됩니다. *** *** 개인정보가 포함된 경우 혹은 불법적인 요소의 수정은 가능합니다.*** -----------------------------------------------------------... 4 0 2399
호이짝
2017.02.12
5526 diem 코인 폴로에서 없어졌는데 *** 답변 댓글이 있을 때 글 내용 삭제시 경고 없이 계정이 정지됩니다. *** *** 개인정보가 포함된 경우 혹은 불법적인 요소의 수정은 가능합니다.*** -----------------------------------------------------------... 2 0 622
sunnydua
2017.02.12
5525 Blockchain 지갑 id alias 질문입니다. *** 답변 댓글이 있을 때 글 내용 삭제시 경고 없이 계정이 정지됩니다. *** *** 개인정보가 포함된 경우 혹은 불법적인 요소의 수정은 가능합니다.*** -----------------------------------------------------------... 0 452
mangsoogi
2017.02.11
5524 바이트볼 다들 들어오셨는지요? 저는 아직까지 안들어왔네요;; 20 0 2092
경제적자유
2017.02.11
5523 ok코인 선물관련. *** 답변 댓글이 있을 때 글 내용 삭제시 경고 없이 계정이 정지됩니다. *** *** 개인정보가 포함된 경우 혹은 불법적인 요소의 수정은 가능합니다.*** -----------------------------------------------------------... 0 763
트럼프
2017.02.11
목록
Board Pagination Prev 1 ... 852 853 854 855 856 857 858 859 860 861 ... 1134 Next
/ 1134
default debug random = 0 / type = READ / detected = READ