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
번호 제목 추천 수 조회 수 글쓴이 날짜
6117 올게 왔다고 생각하세요. 우연한 기회에 2014년도 부터 비트코인을 알게 되어서 나름 작지만 채굴장도 운영해보고 트레이딩이라고 하긴 거창하고 나름 투자하면서 이 시장을 바라보면 요즘의 이런 모습은 사실 올게 왔다고 생각합니다. 차리라... 7 6 1562
부랑카카
2018.11.16
6116 Bitfinex는 Bitcoin ABC 와 Bitcoin SV 로 쪼개졌네요.     Bitfinex 지갑을 보니...   BCH는 잔고가 0 Bitcoin ABC 와 Bitcoin SV에 같은 수량이 들어가 있네요.   어떻게 될려나....???     ㅠ.ㅠ             ------------------------------------- 꼬리말 * 게시글 내... 10 1 1004
미남자TG
2018.11.16
6115 비캐 하드포크 ABC가 이겼나요? 안녕하세요.   차트의 가격만 본 느낌으로는... ABC가 SV보다 월등히 올라가는걸 봐서는... ABC 진영이 이겼든지 굉장히 유리하다든지 하는 느낌입니다만...  정보를 아시는 분 계시는지요?       감사합니다.     --... 25 file 1 2024
크림메일
2018.11.16
6114 이제 매수 들어갑니다.   코인베이스(현재 빗파차트는 신뢰하지 않습니다, 지난번 테더 뱅크런 사태 이후 200-300불이상 프리미엄이 꺼지지 않고 있음) 시세 기준 5.2k까지 확인한 시점에서....   올해초 17k에서 던지는  친구놈 보고 바보... 22 12 2434
네오카인드
2018.11.16
6113 BCH 해시전쟁은 게임끝난듯이 보입니다 BCH 해시전쟁은 게임끝난듯이 보입니다   https://cash.coin.dance/blocks 에서 block details 보면 am 3:00 부터 ABC &gt; SV 로 역전된 상태가 계속 지속되고 있습니다.     이대로라면 bitcoin.com의 비트코인 해시파... 26 file 1 1990
구탑
2018.11.16
6112 브라질산 Niobio(NBR) 코인 떡상했었네요..^^ 안녕하세요..  Cryptonight Heavy 알고리즘을 사용하는 NBR 코인.. 걍 남아도는 허접 컴터170 H/Sec 해시로 몇개월 채굴해서 2만개 정도 캐는 중인데..   20~30사토시에 놀던 넘이 11월 초에 240사토시까지 갔다 왔었... 11 file 1 583
듐마
2018.11.16
6111 슬슬 코인 사모으겠습니다 한동안 코인에 신경 끄고 살았다가 어젯밤에 시세 확인 해보니 개 박살이 나있네요   진짜 2018년 초부터 1년 내내 거의 하락만 했네요    2017년 초만 해도 2017년 말에 그렇게 코인 가격이 떡상 할줄은 상상도 못했... 18 4 859
쿠마닷
2018.11.16
6110 저보다도 더한 트레이더가 있네요 ㅋㅋㅋㅋ    stex 거래창인데요~~~~    칼리 매수자 보시면 황당한 가격이 있습니다. ㅋㅋㅋ    아직은 더욱 저가에 매도가 걸려있는데 그냥 그거사면 되지 굳이~~~    더 높게 산다고 호가를 걸어놨네요~~ 갯수가 적지도 않아... 14 file 0 1072
Orabunny
2018.11.16
6109 바이넨스 BCHABC, BCHSV 상장   바이넨스 BCHABC, BCHSV 상장 했네요.   일단 BCHSV가 50%정도 상승하며 달려주고있네요.                         ------------------------------------- 꼬리말 * 게시글 내용 삭제시 레벨 강등 * 질문은 각 주... 3 file 0 774
애이불비
2018.11.16
6108 아프니? 비트코인이 5100불까지 떨어져도 로켓이 없다. 이더 20만원깨지면 집팔고 사겠다는 사람도 나타나지 않는다.   2차 비캐의난을 기대하며 조금 매수했던 BCH 오늘 밥을 던졌다.(BAB) BSV는 끝까지 가져가볼 생각이다. ... 8 file 9 760
굿터치
2018.11.16
6107 프로비넌스 행사 티켓 나눔합니다. 프로비넌스 행사 티켓 나눔합니다.   다음주 화요일(11월 20일) 세빛섬에서 열리는  프로비넌스 행사 티켓 나눔합니다.    프로비넌스(https://www.provenance.events/) 는 아일랜드에 위치한 회사로 블록체인제품이 ... 2 file 0 251
구탑
2018.11.16
6106 ★필독★ oracol xor 을 소개 했던 청록 입니다. L3+를 가지신 분이라면 꼭 읽어 주세요.   오라콜 XOR 코인을 소개합니다. 현재 캐나다에 법인을 설립하고, 벨기에 거래소 및 금융기관과 파트너쉽을 맺고 있습니다. 일단 메인 홈페이지 링크 입니다.(https://oracol.org/) 현재 세계적으로 광고를 진행 하... 84 file 9 2269
청록
2018.11.16
6105 (번역) 이더리움 희망회로입니다. 맞으면 좋겠네요.   트위터상에 속칭 &quot;차트쟁이&quot;인 분들이 많은데 그중 눈에 띄길래 옮겨봅니다.   FatihSK87라는 트윗 아이디를 쓰는 사람이 지난 6월경부터 올려놓은 차트입니다.       6월 21일 “또다른 이더리움 시나리오. 약간 무... 20 file 15 3162
ryanSCB
2018.11.16
6104 [18.11.16] 비트코인캐시 하드포크 대전 Bitcoin ABC 승! 다양한 소식들!   하양이아빠입니다.   ☆ 오늘의 Pick 뉴스 비트코인캐시 하드포크 전쟁의 승자는 Bitcoin ABC   =&gt; 오늘 새벽 1시 40분경 진행된 하드포크의 해시파워 전쟁의 승자는 BitcoinABC 진영이네요. 향후 Sv가 51% 어택을 ... 13 file 11 1541
하양이아빠
2018.11.16
6103 비트캐시를 지옥으로 보내고 있는 세력은 누구? 1. 비캐를 비코보다 채산성 높게 해서 비캐해쉬를 끌어와야하는 우지한, 로저버네인가? (지옥 보내고 폭등 시키려는?)   2. 우지한네 비캐 해쉬를 끌어오지 못하도록 채산성 똥망으로 만들고 있는 크레이그 켈리 연합... 13 1 1378
디엠스토리
2018.11.16
6102 이제는 가야죠~ 안녕하세요.   이렇게 저렇게 비캐 하드포크도 끝나고 조~금 회복하는 분위기인듯 합니다. 올해도 한달반 남았는데 이제는 쭉쭉 좀 올라갔음 하네요..     코인판에 대형 악재 없이~   가뜩이나 불안한 코인판을 휘젖... 34 file 8 1371
크림메일
2018.11.16
6101 ★오라콜 xor★ 코인 다시 한번 검토 해 주세요.   블로그 링크만 걸겠습니다.   https://blog.naver.com/shinkyojung/221397248110   분명 다른 코인과는 다릅니다. 관리자 마인드가 최강입니다.   풀을 만드실줄 아시는 분은 풀 만들어 주시면 지원 해 드리겟습니... 5 7 1089
청록
2018.11.17
6100 비트코인캐시 역프 뭐죠?    코인마캐캡 기준으로 405달러 빗썸 기준으로는 391,000원이니 대략 12% 정도 역프 인거 맞는건가요?    메이져코인중에 이렇게 역프율이 높은건 간만에 본거 같은데 매입해야 되는건지 말아야 되는건지 아리송 하... 9 0 964
깨달음
2018.11.17
6099 삭제한 글입니다 삭제한 글입니다 0 279
NWD
2018.11.17
6098 우린 세뇌당하고 있을지도 모른다 - Twitter Influencer를 경계한다.   스타벅스안의 인어가 자꾸 전진하고 있다는 것 눈치채셨나요?   계속해서 그안에 있다보면 물들게되고 이게 신념으로 바뀌는 순간 우린 세뇌당하게 되는거죠.   제가 질문하나하겠습니다. 여러분 마음속에 비트코인... 9 file 9 1562
굿터치
2018.11.17
목록
Board Pagination Prev 1 ... 853 854 855 856 857 858 859 860 861 862 ... 1163 Next
/ 1163
default debug random = 0 / type = READ / detected = READ