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

     

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

    포스가 느껴집니다.

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

List of Articles
번호 제목 추천 수 조회 수 글쓴이 날짜
8161 야피존 얌이무엇인가요? 일종의 은행이자같은것같은데.. 자세하게 설명해주실분있나요? 2 0 1120
박준원
2014.12.22
8160 잭팟코인 지갑 코인뺄려는데 이상합니다..  비밀번호까지 입력하고 햇는데 이런식으로 메시지가.. 어떻게 해야하나요? ㅠ-ㅠ;; 3 file 0 1735
나기잉
2014.12.23
8159 골드만삭스, 비트코인 강세 전망 BTC 13,971 달러 가격 목표 골드만삭스, 비트코인 강세 전망 “BTC 13,971 달러 가격 목표” 2019년 8월 12일 &lt;12일(현지시간) 코인텔레그래프 보도내용&gt; 골드만삭스는 고객들에게 보내는 메모에서 비트코인 가격 강세 전망을 내놨습니다. 8월 11... 1 file 0 392
메르시
2019.08.13
8158 UNIT 하루만에 2300% 상승           WOW 뭔 일이 일어난걸까요             ------------------------------------- 꼬리말 * 게시글 내용 삭제시 레벨 강등 * 질문은 각 주제별 게시판에.   비트코인 암호화화폐 커뮤니티 땡글~ 땡글~ ------... 1 0 2035
김띵
2017.12.17
8157 속보) ETH 1200만달러 거래소 이체, BTC 고래 지갑서 2.3억 달러 이체 3월 11일  주말 뉴스 브리핑   [美 코네티컷 주, 스마트 컨트랙트 상업적 사용 합법화 법안 발의] 암호화폐 전문 미디어 코인데스크에 따르면, 미국 코네티컷 주정부가 스마트 컨트랙트의 상업적 사용을 합법화 한다... 5 0 3569
코인니스
2019.03.11
8156 비트코인 이슈 정리로 보는 인사이트 안녕하세요, 레드우드입니다.   올해는 뱅크런 외엔 큰 이슈 없이 지나가는 것 같습니다. 하지만 부동산 시장도, 주식 시장도 변곡점을 맞이하면서 하락할 준비를 하고 있는 시점에 올해 비트코인을 정리해보겠습니... 1 file 0 325
에임리치
2023.11.02
8155 요즘 장이 안좋네요.. 요즘 장이 안좋네요..                     ------------------------------------- 꼬리말 * 게시글 내용 삭제시 레벨 강등 * 질문은 각 주제별 게시판에.   비트코인 암호화화폐 커뮤니티 땡글~ 땡글~ ------------... 2 0 575
옴니아
2018.04.21
8154 비트렉스에서 제크를 비트골드로 환전하고 싶은데 가능한가요? 가능하다면 어떻게 어디서 해야하는지 3시간...   하도 오랜만에 비트렉스에 들어가니 머가먼지 하나도 모르겠네요.. 어디메뉴에 가면 제크를 비트골드로 환전이 가능한지요? 비트골드 지갑주소를 생성하려고 해도 에러가 나고 머가먼지 뒤죽박죽 하나도 모르겠네... 11 file 0 740
신셰계
2018.01.07
8153 업비트는 계속 KRW 입금 불가...ㅠㅠ 망할.... 다른 거래처들 정보가 필요합니다.   이거원.... 뭐하자는거지....ㅠㅠ 다른 거래처거래소들 국내와 해외 거래처거래소 좀 알려주실분...ㅠㅠ 이밤을 지세워서 쓰러져 잘거 같지만....ㅠㅠ;   ------------------------------------- 꼬리말 * 게시글 ... 16 0 1499
mercury
2017.12.07
8152 도기코인 부활하나요? 오늘 거래량도 폭발적으로 늘면서 50퍼센트 이상 오르네요~ 3 0 1730
부랑카카
2014.08.26
8151 eos 빗섬 입금 관련해서..         혹시 바이낸스에서 빗섬으로 eos 입금 하신분중에서 몇시간 걸리셧나요?? 저는 5시간째 입금이 안되고 전화도 안되고 게시판 답변도 안달아주네요~~~               ------------------------------------- ... 6 0 868
아리2
2017.12.14
8150 고팍스 입금 하다 인증 코드를 cme 코드에 넣었는데요           이게 아무리 생각해도 이름에 넣는거 같지 않아서 그냥 cme 코드에 넣었는데 입금하고 20분 지나도 확인이 안되네요      아우 ~~~`   입금 하는거 진짜 개 드럽네요 -_-   그냥 코빗에 할껄 .... 아우~ 이... 2 0 1255
소박하게캐자
2018.01.07
8149 점점 매도 압력도 심해진다는 말이겠죠. [01월 02일 에임리치 데일리 코인시황 브리핑]   안녕하세요. 에임리치 그레이 입니다.   ----------------   [쉽게 읽는 한 줄 뉴스]   -파산 전문 변호사 &quot;FTX 사태 해결까지 수년 소요 전망&quot;   -비탈릭 부테린, 20... file 0 178
에임리치
2024.01.02
8148 알트코인 트레이드 하기전에 읽어볼만한 책있을까요??       혹시 괜찮은 책 있나요??   가상화폐 책은 별로 없으니 주식책을 읽어봐야할까요??   가상화폐로 3달에 3억벌었다 책 괜찮을까요??                 ------------------------------------- 꼬리말 * 게시글 내... 13 0 1173
wdpark
2017.12.29
8147 이더하고 비트코인 중에서 주식 투자처럼 해볼려고 고민중인데 잘 아시는분들 설명좀.... 보안을 기준으로 봤을때 비트코인이 안정적인 대신에 실거래가가 높고   가격 저하상승값들을 봤을 때는 이더가 무한생산물량빨이라 그런지 아니면 원래 낮아서 그런지 이더가 더 안정적인 모양입니다.   국내 거래소... 0 972
silent
2016.12.22
8146 조정이 좀 쎈데요? 오전에 익절하고 11500 최대 최대저점으로보고 예약매수하고 목욕다녀오니 이게 뭥미 반등온뒤 계속 떨어지네요 ㅡ.ㅡ;; 15 0 4074
스팅어하이
2018.01.21
8145 으음 업비트 쓰고있는데 아쉬운부분이... 입출금 계좌가 원화 비트코인, 이더리움 등 몇개밖에 없네요... 새벽 아침에 대쉬시세차가 꾀났는데 ㅠㅠ 보면서 그냥 눈물만   지갑이라는게 중개소에서 만들고 관리하기 힘든가보네요                     --------... 2 0 1172
율루루
2017.11.21
8144 재정거래하려면 해외구매 장외거래소 이용하라는건 무슨말인가요? 낮에 질문글에 답글주신분이 있는데 해외 장외거래소 이용해서 재정거래 할수 있다는거 같은데 어떻게 하는건가요? 카드로 연간한도 내에서 해보려고 했는데 카드구매를 막아놔서 다른 방법을 찾는중입니다. 방법아시... 3 0 1520
제이팸
2018.01.14
8143 마운트곡스 홈페이지 공지 : 자신의 계정의 비트코인 잔고를 확인하세요 https://www.mtgox.com/ 마운트곡스 홈페이지 공지 : 자신의 계정의 비트코인 잔고를 확인하세요 Important announcement to all users confirming their account This balance confirmation service is provided on... 2 file 0 758
비트코인박사
2014.03.18
8142 도기코인 지갑 도기코인 지갑 어떻게 만드나요? 0 3818
부자왕자
2014.01.18
목록
Board Pagination Prev 1 ... 752 753 754 755 756 757 758 759 760 761 ... 1165 Next
/ 1165
default debug random = 0 / type = READ / detected = READ