EOS.IO 개발 업데이트 ( 한글 번역본 - 최종 )

아래 글은 2018.1.13 일 발표된 EOS.IO Development Update 를 번역한 것입니다. 많이 읽어주세요! 이오스 가즈아ㅏㅏㅏ

<hr /> <p dir="auto"><img src="https://images.hive.blog/768x0/https://steemitimages.com/DQmcGovc44CVkutoMdP8wAzYwkCYj9RJ8vWyoidsXi3dTdW/image.png" srcset="https://images.hive.blog/768x0/https://steemitimages.com/DQmcGovc44CVkutoMdP8wAzYwkCYj9RJ8vWyoidsXi3dTdW/image.png 1x, https://images.hive.blog/1536x0/https://steemitimages.com/DQmcGovc44CVkutoMdP8wAzYwkCYj9RJ8vWyoidsXi3dTdW/image.png 2x" /> <p dir="auto">저희 팀은 EOS.IO 를 최고의 스마트 컨트랙트 플랫폼으로 만들기 위해 정말 바쁜 시간을 보냈습니다. 저희 팀은 성능과 개발 난이도 사이의 균형을 잡아 블록체인의 한계를 넘어서기위한 노력을 했습니다. <p dir="auto">이전의 업데이트에서 저희 팀은 아래와 같은 목표를 바탕으로 일하고 있다고 전해드렸습니다. <ul> <li>애플 터치아이디 지원 / Secure Enclave(보안 구역 - APPLE 공식문서) <li>지연된 거래의 에러 핸들링 <li>병렬 실행 (Parallel Execution) <p dir="auto">그 업데이트 이후로 저희팀은 목표했던 많은 것을 이뤘습니다. 마스터 브랜치의 안정성을 위해 대부분의 작업물은 깃헙의 <code>eos-noon 브랜치에서 이뤄지고 있습니다. 아래는 저희 팀이 해온 일에 대한 자세한 내용입니다. <h1><strong>Deferred Transactions (지연된 거래) <p dir="auto">Deferred transactions 은 데이터베이스 동시에 얻어야하는 잠금(lock)을 최소화하여 다른 Shard(데이터 노드 클러스트) 간의 커뮤니케이션을 원할하게 합니다. 이는 거래 예약 기능과 예약된 거래 취소기능과 함께 구현되어 있습니다. <p dir="auto">예약 거래(와 무료 거래)는 EOS.IO 를 최초의 “튜링-완전 스마트 컨트랙트 플랫폼”으로 만들어주는 기능입니다. 이 뜻은 EOS를 통해 초당 여러개의 스마트 컨트랙트를 자동으로 수행될 수 있게 한다는 것입니다. 대역폭만 충분하다면 스마트 컨트랙트는 영원히 지속될 수 도 있습니다. 다른 스마트 컨트랙트 플랫폼들에서는 수수료제한이나, 예약 기능의 미지원으로 외부의 입력없이는 스마트 컨트랙트가 지속될 수 없습니다. <p dir="auto">이 기능은 2018년 Q1 으로 예정된 EOS Dawn 3.0 테스트넷 배포버전에서 가능해질 것입니다. <h1><strong>Authorization Delays(권한에 따른 지연) <p dir="auto">시간은 보안의 중요한 요소입니다. 저희팀은 <a href="http://eos.IO" target="_blank" rel="noreferrer noopener" title="This link will take you away from hive.blog" class="external_link">EOS.IO 의 권한 구조 수정을 진행하고 있습니다. 권한 구조를 수정함으로, 유저는 권한에 따라 필수적인 지연들을 설정할 수 있습니다. 예를 들어, 소셜미디어 포스팅은 즉각적으로 이뤄질 수 있게 하고, 코인을 전송하는 일은 24시간 이상의 딜레이가 발생하도록 하는 식입니다. 유저가 딜레이가 있는 액션을 취할 때, 해당 거래는 다른 지연 거래들과 묶인 상태로(packaged) 존재하고, 언제든 취소하는 것이 가능합니다. 이는 유저가 해킹된 계정으로 부터 심각한 손해를 입기전에 해당 계정을 복구하는 것을 가능케 합니다. <h1><strong>Hacked Account Recovery( 해킹 계정 복구 ) <p dir="auto">모든 계정은 세 가지 특별한 권한을 갖습니다. : owner(소유), active(활성), recovery(복구). Owner 권한은 멀티시그(N of M Multisig) 를 통해 설정되며 모든 권한을 즉시 변경할 수 있습니다. Owner 권한의 수정은 30일의 딜레이를 갖습니다. 이상적으로, owner 권한은 파트너(Recovery Partner)계정의 승인도 필요 합니다. Owner 권한을 해킹하기 위해서는 파트너 계정도 동시에 해킹되어야만 합니다. 만약 파트너의 active 키가 해킹되었다면, 파트너는 그들의 Owner 권한으로 계정을 복구할 수 있습니다. 결과적으로, 이런 신뢰의 망(web)은 모든 이가 동시에 해킹당하지 않으면 해킹이 불가능하도록 설계되었습니다. <p dir="auto">만약 파트너가 비 협조적이기로 결정했다면, Active 권한은 30일의 지연을 갖고 일방적으로 Owner 권한을 수정할 수 있습니다. 결국 유저의 계정은 다른 이에 의해 변경될 수 없음을 뜻합니다. 한 가지, 마지막 시나리오는, 액티브 키를 잊는 것과 동시에 해커가 이 키를 얻는 것입니다. 물론 이는 백업 등으로 충분히 예방할 수 있습니다. <h1><strong>Lost Password Recovery( 비밀번호 분실 복구 ) <p dir="auto">사람들은 언제나 비밀번호를 잊습니다. 머피의 법칙은 모든 것이 잘못될 수 있음을 말합니다. 그리고 이런일은 암호화폐 전문가들에게도 일어날 수 있는 일입니다. EOS.IO 에서는 그럴 걱정은 없습니다. 모든 계정에는 active 권한(7일 딜레이)을 갖는 파트너(recovery partner)가 있기 때문입니다. 그러나 오직 유저의 계정이 30일 동안 비활성화 된 상태일 때만 적용되는 이야기 입니다. 키를 잃어버리더라도, 유저가 친구나 가족등 믿는 사람들로 부터 계정을 돌려받을 수 있다면, 계정 복구는 걱정할 필요가 없습니다. <p dir="auto">모든 다른 계정은 유저의 계정을 복구하는데 도움을 줘야할 법적인 의무를 갖습니다. 누군가 30일의 비활성화 계정상태를 악용하여 유저의 계정을 취득하려 한다면, 법적인 조취를 취해 계정을 돌려받을 수도 있습니다. 왜냐하면, 유저는 오직 지인만을 복구계정으로 지정할 것이기 때문입니다. 이는 쉽게 누가 책임을 갖고 있는지 가려내는데 도움이 됩니다. <p dir="auto">비밀번호 분실은 사회적 관계와 지연(time delay) 암호학 등을 통해 구축된 신뢰망으로 예방되며, 모든 계정은 안전하게 유지될 수 있습니다. <h1><strong>Update Resource Usage Algorithms (리소스 사용 알고리즘 업데이트) <p dir="auto">EOS Dawn 2.0 은 기본적인 리소스 제한을 구현했습니다. 지난 두 달 동안, 저희 팀은 대역폭, Computation, 투표, 용량 등의 리소스 제한 전략을 크게 수정했습니다. <h2><strong>Separate Staking(분할 스테이킹) <p dir="auto">가장 큰 변화는 권한 별 스테이킹 풀입니다. 대역폭, 메모리, 컨트롤 등 권한 별로 경제의 기본적인 공급/ 순환 법칙을 따르는 스테이킹 풀을 만들었습니다. 예를들어, 우리는 다른 이들이 그저 투표나 대역폭을 더 갖기 위해 그들이 사용하지 않을 메모리를 할당할 수 있도록 하고 싶지 않습니다. 우리는 또한 Unstaking(Staking 취소)과정에 3일의 지연을, 사용하지 않는 저장소는 즉시 Unstaking 할 수 있도록 하며, voting Unstaking 에는 6달이 걸리도록 강제합니다. 대역폭과 voting 은 위임될 수 있으나 저장소는 위임될 수 없도록 합니다. 여기에서 보는 것처럼, 많은 니즈들이 설정될 수 있습니다. <h2><strong>Bandwidth Delegation (대역폭 위임) <p dir="auto">어떤 계정이든 대역폭 Staking 계정에 토큰을 보냄으로 다른 계정에 대역폭을 위임할 수 있습니다. 같은 방식으로 유저는 스스로에게 '대역폭을 위임' 할 수 있습니다. 유저는 3일의 딜레이를 거쳐 토큰을 다시 가져올 수 있습니다. 대역폭 비용은 거래를 인가하는 모든 계정에게 부과될 것이며, 3일의 미사용기간 동안 0으로 수렴됩니다. <h2><strong>Voting (투표) <p dir="auto">이제 구분된 pool 을 가게 되었으니, 우리는 정치적 권한을 행사하고 싶은 유저들에게, 더 나은 권한 분배를 할 수 있습니다. 블록생성자 선택 권한이나, 프로토콜 업그레이드에 대한 영향력을 갖기 위해서는, 사용자는 의무적으로 한 Contract 에 토큰을 6개월 이상 투자(Stake)해야 합니다. 이를 통해, 그들이 플랫폼에 부정적인 영향을 주게 되면 그들은 토큰을 잃게 될 위험에 처할 수 있게 됩니다. <h2><strong>Memory (메모리) <p dir="auto">랩은 비싸고 제한된 자원입니다. 만약 1TB 의 RAM 을 총액 $100B의 시장에 할당한다고 한다면, 이는 마치 바이트당 $10 에 달하는 비용을 부과하는 것과 다름 없습니다. 이는 램이 필요하지 않은 99.99% 의 토큰 유저들에게 플랫폼을 사용할 수 없게 하는 것과 다름 없습니다. <p dir="auto">이 문제를 해결하기 위해 우리는 Bancor 가 메모리를 1% 예약 형태의 스마트 토큰으로 취급하는데에서 아이디어를 얻었습니다. 이 경우, 예약 가능한 메모리는 1TB 가 되고, Bancor 알고리즘은 이 메모리를 변동 가격에 판매하여, 메모리가 동나지 않게 합니다. 유저가 램을 예약(reserve, 역주 : 사용)하려면, 그들은 메모리 계약(contract) 에 토큰을 보내고 토큰의 가치와 사용가능한 메모리에 따라 예약된 bytes가 정해집니다. <p dir="auto">블록체인은 실제 사용량을 추적하고 할당된 것보다 많은 메모리를 사용하려 할때 거래를 취소합니다. 메모리가 필요치 않을때 할당된 메모리를 줄이고 투자된 토큰을 돌려받을 수 있습니다. <p dir="auto">예약된 저장소를 할당하거나 전해주는 것은 불가능합니다. 싼 가격에 예약된 램을 비싸게 푸는 등의 거래는 불가능 합니다. 이는 저장소가 사람들의 실제 이용가치를 넘어서 투자되는 것을 방지합니다. <p dir="auto">각 유저는 하루에 한번 할당량을 증가시킬 수 있습니다. 완전한 할당에 지불하는 비용은 할당 이후 사용되지 않은 메모리에 따라 달라집니다.이는 한 번에 많은 메모리를 할당하는 것이 굉장히 비싸고(시장의 이탈이 발생하므로), 시간에 따라 사용할 만큼만 저장소를 사는 것이 가장 저렴한 방식임을 뜻합니다. <p dir="auto">This strategy will cause those who want to reserve a lot of RAM to dollar cost average and give all competitors similar prices over time. <h2><strong>Billing Memory Usage (메모리 사용 비용) <p dir="auto">우리는 어떻게 어플리케이션을 사용가능하도록 만들지 알게되었습니다. 알게된 것 중 하나는 많은 케이스에서 유저가 자신의 저장소를 사용할때 Contract 소유자는 더 많은 이득을 취할 수 있다는 것입니다. 유저에게 이 비용을 전가하지 않으면, 특정 병렬 계산을 어렵게 만들고 개발자 스스로 비즈니스 모델을 만들어야만 합니다. 모든 contract 는 저장소 비용을 유저에게 청구하거나, 스스로가 지불할 옵션을 갖습니다. 대부분의 케이스에서 유저는 스스로의 계정 정보를 저장하는 것이 효과적입니다. 이는 개발자에게 사용성을 위한 최고의 유연함을 제공해 줄 것입니다. <p dir="auto">이 변경사항은 EOS Dawn 3.0 에 포함되는 것으로 예정되어있습니다. <h1><strong>Implicit Transaction Locking (암묵적 거래 락) <p dir="auto">우리는 “read/write scopes”(읽기/쓰기 범위) 를 “read/write locks”(읽기/쓰기 락) 이라는 이름으로 변경했습니다. 이는 이 액션의 행위를 설명하는 말이자, 락의 granularity를 증가시켜 병렬 실행의 기회를 극대화 합니다. EOS Dawn 2.0 를 테스트 하는 개발자들은 거래마다 지정해야하는 “scopes” 의 필요성에 대해 잘 알고 있을 겁니다. 이는 Transaction 을 만들기 어렵게 하고, 동적 상황에 취약할 수 있습니다. 우리는 그 상황을 조사하여 블록 생성자가 어떤 read/write locks 이 필요한지 결정할 수 있도록 했습니다. 이로 인해 모든 거래에 락의 필요가 없어졌으므로, 개발자에게 더 쉬운 작업을 가능케 합니다. <p dir="auto">이 변경사항은 <code>eos-noon 브랜치에 구현되어 있습니다. <h1><strong>Dynamic Upgrades of Core Features(코어 기능의 동적 업그레이드) <p dir="auto">일반적으로, 블록체인의 업그레이드를 위해서는 하드포크가 필요합니다. 이는 새로운 기능이 생겼거나, 기존의 기능이 업그레이드 필요할때, 버그가 수정되어야 할 때마다 필요합니다. 하드포크는 모든 네트워크에 파괴적인 영향을 줍니다. 그러므로 WASM을 이용해 블록체인의 기능이 동적으로 정의 되어 있는 것이 바람직합니다. 우리는 주요 기능을 native C++ 에서 WASM 으로 변경하고 있습니다. 그 기능들은 다음과 같습니다. <ul> <li>The core token (e.g. EOS) <li>Staking for bandwidth, memory, and voting <li>Producer voting <li>Multisig Contracts <li>Community Benefit Contract / Worker Proposal allocation <p dir="auto">WASM 을 통해 정의되지 않을 transaction 들은 아래와 같습니다. <ul> <li>Account creation <li>Bandwidth / RAM usage metrics <li>Permission Updates <h1><strong>Scheduled / Deferred Transactions (예약, 지연 거래) <p dir="auto">이 변경사항으로인해 블록 생성자는 하드포크 없이 여러 방면의 프로토콜의 버그를 수정하고 업그레이드를 진행할 수 있습니다. 이 과정을 통해 우리는 개밥먹기(역주 : 개발자가 자신의 제품을 스스로 테스트하는 것) 와 우리의 스마트 컨트랙트 개발 환경이 상상하는 모든것을 구현할 수 있을 정도로 튼튼함을 보증할 수 있습니다. <h1><strong>Emerging Token Standard (토큰 기준) <p dir="auto">여러 계약간의 상호운융가능성을 지키려는 노력에 따라, 계약의 토큰 기준을 세우고자 합니다. 이 기준은 ERC-20 토큰이 갖는 아이디어 와 비슷하며, 이 토큰은 여러 계약들간에 사용이 가능하도록 설계됩니다. <p dir="auto">토큰 기준은 기존의 ERC-2* 토큰에 비해 여러 장점을 갖습니다. <ul> <li>전송에는 메모를 첨부할 수 있음 <li>발송자와 수신자는 코드를 실행하거나 거래를 거절할 수 있음 <li>EOS.IO 의 권한 시스템에서 얻는 이점 <li>Native tokens 들도 동일한 코드로 구현가능 <li>하나의 Contract 가 여러 토큰을 생성하고 관리할 수 있음 <p dir="auto">우리는 우리의 토큰을 생성하는 과정이 템플릿에 변수를 넣는 것처럼 간단하게 만들 C++ 라이브러리 를 만들고 있습니다. <h1><strong>Focus on Stability (안전성에 초점) <p dir="auto">우리의 싱클 쓰레드 기반 코드는 0.5 초의 블록 생성 간격을 두고 5000 TPS 를 수행할 수 있도록 만들어졌습니다. 그리고 2초 안에 최종성(finality)을 도출합니다. 이는 이 분야 최고의 성능입니다; 그러므로 우리는 이 시장이 안정성과 기능, 그리고 더 나은 설계방식으로 부터 많은 혜택을 받을 수 있다고 생각합니다. 그러므로, 우리는 초당 거래를 최대화하는 것 보다 모든 거래의 품질을 올리는데 초점을 맞추고 있습니다. <p dir="auto">Dawn 2.0 업데이트에서 우리는 병렬 실행 (parallel execution)을 원래 계획된 것 보다 일찍 진행한다고 알려드렸습니다. 많은 개발자에게 친화적인 기능이 추가됨에 따라, 우리는 6월 EOS.IO 릴리즈를 위해 안전성을 퍼포먼스보다 더 중요하게 다루기로 했습니다. 우리는 시장에서 바로 사용될 기능을 최고로 설계를 하는 것이 조악한 결과물을 내놓는 것보다 더 나은 것이라고 판단했습니다. <p dir="auto">체인간 커뮤니케이션의 개발로, 우리는 EOS.IO 가 무한 스케일링을 쉽게 지원할 수 있을 것이라고 생각합니다. 이 기능은 많이 구현되었으며 이 기능의 proof-of-concept 데모를 Q2 에 가능할 것이라고 기대하고 있습니다. <h1>Byzantine Fault Tolerant(BFT) DPOS <p dir="auto">두 POS(proof of stake) 시스템이 있습니다. DPOS와 tendermint와 같은 BFT입니다. 두 시스템은 다른 장점을 갖습니다. DPOS 는 빠른 블록생성시간을 보장하며 (0.5 second) 하나의 블록생성자만 있다면 제 기능을 다할 수 있습니다. 단점은 기존의 DPOS는 최종확정성(absolute finality)에 도달하는데에 45 초가 걸린다는 것입니다. 스팀과 빗쉐어(BitShare)의 경우, 99.9% 최종성을 2초만에 도달할 수 있으나, inter-blockchain 커뮤니케이션의 경우 최종확정성에 2 초 안에 도달하게 됩니다. <p dir="auto">BFT 시스템은 매 블록생성마다 최종확정성을 갖습니다. 그러나 알고리즘이 많은 대역폭을 소모하고, 2~ 3초동안 99.9% 최종성을 아무런 중간단계없이 갖게됩니다. 게다가, 33% 의 노드가 정지하면 시스템 조차 정지합니다. BFT-DPOS 는 두 시스템의 장점을 갖습니다. 블록은 99.9% 의 최종확정성을 갖고 매 0.5 초마다 생성되고, 2초마다 최종확정성을 갖게 됩니다. 우리는 블록생성자들로 하여금 그들의 로컬 체인이 생성될 때마다 블록컨펌을 하도록 하여 가능케 했습니다. byzantine fault 은 블록생성자가 같은 블록에 대해 두 컨펌을 보낼때 발생합니다. 블록 생성자는 증가하는 숫자(incrementing number) 와 함께 컨펌을 보냅니다. 같은 숫자와 함께 두 컨펌을 보내는 사람을 byzantine으로 판명할 수 있습니다. <p dir="auto">오직 한 블록생성자만 하나의 블록을 생성할 수 있고, 생성자들은 더 긴 체인이 발견되면 다른 체인으로 이전하기만 하기때문에, 새로운 체인을 만들고자하면 ⅓ 이상의 블록생성자가 byzantine faults 문제를 해결해야 합니다. 이 때, 커뮤니티는 블록생성자의 계정을 비활성화( freeze )시키거는 식으로 그 블록생성자는 블록 스케줄에서 제외될 수 있습니다. 이렇게 DPOS 체인은 가장 긴 체인을 통해 유지될 수 있습니다. <h1><strong>Compensation for Runner Up Block Producers (블록생성자 보상) <p dir="auto">우리는 블록생성자의 수익을 두 계층으로 나누는 작업을 진행하고 있습니다. : <ul> <li>Per-block reward ( 블록 당 보상 ) <li>Per-vote reward ( 투표 당 보상 ) <p dir="auto">모든 투표가능한 블록 생성자들은 거래에 서명함으로서 매 시간마다 투표 당 보상을 받을 수 있습니다. 그러기 위해 그들은 최소한 거래를 알리는(broadcast) 봇을 갖고 있어야 합니다. 이 보상체계로 인해, 블록생성자들은 계속 투표를 할 동기를 갖게 됩니다. <p dir="auto">우리는 또한 vote-decay( 투표 부식, 쇠퇴 ) 시스템을 통해 오래된 투표보다 최신의 투표가 더 높은 비중을 갖고록 했습니다. 이를 통해, 최신의 투표를 많이 가진 사람이 블록생성자가 되기에 유리해집니다(매달 갱신). 이전의 투표는 2년 이후 최소한의 영향만 갖게 됩니다. <h1>Growing Team ( 팀의 성장 ) <p dir="auto">이번 주 우리는 8명의 새로운 사람을 팀으로 들였습니다. 우리는 언제나 능력있는 개발자와 디자이너를 찾고 있습니다. <h1><strong>Conclusion ( 결론 ) <p dir="auto">EOS.IO 는 2018년 6월 릴리즈를 위해 튼튼하게 성장하고 있으며 백서에 기록된 것들보다 더 많은 것을 이루고 있습니다.