EOSIO Dawn 4.0 출시

Translated Contents

원문: https://medium.com/eosio/eosio-dawn-4-0-release-b25661a49ac2

지난주에 우리는 EOSIO Dawn 4.0을 소개드렸고, 오늘 우리는 EOSIO 의 주요 예고편을 공개하게 되어 뿌듯합니다. 지난주에 참 많은 일들이 일어났습니다.

Retrieved from the original source: https://medium.com/eosio/eosio-dawn-4-0-release-b25661a49ac2

Dawn 4.0 RAM 배당에 관한 피드백

몇몇 커뮤니티 멤버들은 누군가가 사람들이 체인에 올라가기도 전에 싼 RAM을 미리 대량으로 구매해서 부당한 이익을 취할 것에 대해 우려를 표했습니다. 이 이슈를 해결하기 위해서, 체인을 론칭하는 사람들은 매우 제한적인 RAM 용량을 가지고 시작하되, 첫 두 달 정도에 걸쳐 점진적으로 RAM을 늘려가는 방법을 추천합니다. 만약 RAM 공급이 32GB에서 시작한 후 몇 달에 걸쳐서 1TB로 늘어난다면, RAM 가격은 초기 가격에 비해 3% 정도의 수준으로 급격하게 떨어질 수 있습니다. 정말 RAM이 필요한 사람들이나 미래의 RAM 공급량을 미리 고려하는 사람들만 초기 RAM을 살 것입니다. 어떤 방법으로든, 아무도 “비정상적으로 싼” RAM을 갖거나 공짜 이득을 보는 사람은 없을 것입니다.

테스트 네트워크 상황

유럽과 아시아, 그리고 미국에 노드를 둔 우리의 내부 테스트 네트워크는 심각한 문제없이 잘 작동하고 있습니다.

주관적(Subjective) CPU 자원 사용의 재개

지난 몇 달간 우리는 객관적인 CPU 청구(billing) 방법에 대해 실험해 왔습니다. 객관적인 청구방법은 한 트랜잭션이 사용하는 CPU 명령의 개수를 결정론적으로 계산하는 것입니다. 이 방법은 한 트랜잭션에서 어떤 자원이 소비되는지에 대해 명확하고 완전한 합의가 이루어질 수 있도록 합니다. 이 방법은 다른 스마트 컨트랙트들에서 많이 쓰이고 있습니다.

우리가 EOSIO를 1년 전에 소개했을 때, Subjective Best Effort Scheduling을 사용하는 것을 제안했습니다. 이 모델은 각각의 블록 프로듀서가 트랜잭션을 수행할 때 소요된 벽시계 시간(wall-clock time)을 측정하고 사용자에 그만큼을 청구하는 것입니다.

사용량에 대한 합의를 유지하기 위해서 블록 프로듀서는 트랜잭션에 청구한 시간(몇 microsecond 인지)을 보고할 것입니다.

객관적 청구방법이 합의를 간단하게 만들고 청구에 관한 분쟁을 없앤다는 좋은 장점이 있지만, 다음과 같은 단점들이 여전히 존재합니다.

1. 객관적 CPU 측정은 추가적인 데이터를 저장해야 하기 때문에(bookkeeping) 성능을 저하시킬 수 있습니다.
2. 객관적 CPU 측정은 언제든 실제 가격과 객관적 근사치에 불일치가 있을 경우 공격과 DoS(denial of service) 벡터에 취약해질 수 있습니다.
3. 객관적 CPU 측정은 유지, 업그레이드, 최적화가 어렵습니다.

하지만 주관적 청구방법은 특히 합의 시스템에 있어서 해결해야 할 이슈가 있습니다. 다행히도 우리는 이것을 가능하게 하는 혁신적인 해결책이 있습니다. 해결해야 할 이슈들은 다음과 같습니다.

1. 정확한 사용량을 보고하는 것에 있어서 블록 프로듀서를 신뢰하는 것
2. 블록 프로듀서 간의 의견 차를 해결하는 것(하드웨어, 소프트웨어, 로드(load)에 따른 의견차)
3. 악의적인 블록 프로듀서를 처리하는 것

위임 지분 증명(DPOS)에서 블록 프로듀서들은 계약의 의무가 있고, 악의적인 행동에 대한 법적인 책임 아래 있는 공적인 단체입니다. 또한 모든 21개의 액티브 블록 프로듀서들은 그들을 뽑은 커뮤니티 안에서 높이 평가되는 단체일 것입니다.

이런 가정 하에, 우리는 모든 블록 프로듀서들이 CPU 실행시간(runtime oracles)과 트랜잭션이 얼마나 오래 걸렸는지에 대해 거짓말하지 않을 것이라 신뢰할 수 있습니다. 정상적인 운영 조건 하에서 우리는 보고된 실행시간이 모든 블록 프로듀서 간 평균 실행시간의 합리적인 오차범위 내에 있을 것이라고 믿을 수 있다는 것입니다.

이 접근 방식에 대한 비판으로는, 예를 들어 하나의 악의적인 블록 프로듀서가 무한 루프가 있는 블록을 생성하고 그것에 대해 걸리는 시간이 없다고 보고하는 것입니다. 이것을 방지하기 위해 모든 노드는 모든 블록의 실행시간에 2초의 캡(cap)을 주는 것입니다. 하지만, 캡이 있다고 해도 네트워크에 어느 정도의 분열을 줄 수 있습니다. 요령 있는 악의적인 블록 프로듀서는 50% 노드는 찬성하고 50%의 노드는 거부해서 네트워크를 분열시키는 블록을 만들 수도 있습니다.

우리 팀은 공격 벡터(vector)를 분석한 결과 실행시간이 매우 긴 블록은 매우 긴 네트워크 지연이나 정지와 다를 것이 없다고 결론 내렸습니다. 네트워크 분할(Network Partition)에 있어서 강력한 합의 알고리즘이라면 다른 주관적인 면에 있어서도 강력할 것입니다. BFT 위임 지분이 네트워크 분할을 버텨낼 수 있기 때문에, 악의적인 프로듀서가 분열 상황을 만드는 것도 버텨낼 수 있을 것입니다.

블록 프로듀서들이 네트워크 분할의 가능성을 낮출 수 있는 몇 가지 방법이 있고, 이 방법들은 네트워크 분할의 이유가 대서양의 광섬유 케이블을 자르는 것이던 악의적인 프로듀서이던지 같습니다.

1. 여러 커넥션을 유지하기

이 접근 방식으로 만약 대서양 사이의 연결이 끊어진다면 프로듀서는 패킷을 태평양을 통한 경로로 돌릴(route)할 것입니다. 블록들을 승인할 때 프로듀서는 여러 개의 승인 노드들이 있을 것이고 절대 두 개의 노드가 한 개의 블록을 승인하려고 시도하지 않을 것입니다. 가장 극단적 케이스로는 각각의 프로듀서가 peer 프로듀서로부터 오는 블록을 처리하기 위해 노드를 지정해 놓는 것입니다. 만약 하나의 프로듀서가 승인 채널을 무한 루프로 막아버린다면 다른 프로듀서로부터 오는 블록은 그들의 독립적인 남는 채널을 통해 처리될 수 있을 것입니다. 비가역 블록 넘버가 나쁜 (무한 루프가 있는) 블록을 넘어간다면, 그 노드는 블록 프로세싱을 끝내버리고 종료하도록 강제할 수 있습니다. 이에는 2/3 이상의 프로듀서의 비잔틴 중단(stop) 합의가 필요합니다.

2. 복구 혹은 경로 우회하기

광섬유 케이블 중 하나가 끊겼다고 해서 그것을 대체할 여러 개의 광섬유 케이블 갖고 있는 것이 항상 가능하진 않습니다. 그럴 경우에 팀이 파견되어 손상 입은 케이블을 고치고 다시 연결시키도록 할 것입니다. 이 방법은 시간이 더 걸릴지 몰라도 결과적으로 다시 연결이 되어 네트워크는 약간의 다운 타임 후에 합의 프로세스를 을 진행할 것입니다. 만약 악의적인 프로듀서가 있다면 다른 프로듀서들은 그들의 configuration 내용을 업데이트해 악의적인 프로듀서를 블랙리스트에 올리고 정상적인 운영을 재개하면 됩니다. 악의적인 프로듀서를 블랙리스트에 올리는 행위는 심지어 비정상적으로 긴 실행시간(runtime)이 관찰될 시에 자동화될 수 있습니다. 최악의 시나리오는 악의적인 프로듀서가 추방 한계점에서 블록을 조작해 오직 전체 프로듀서들 중 반만이 블랙리스트에 그를 올리도록 하는 것입니다. 이 경우에는 다른 프로듀서들이 어떤 포크를 따라갈지 결정하는 동안에 비가역 블록 승인을 멈출 것입니다.

이 모든 경우에 마지막 비가역 블록에 의지하는 사용자들은 double spend 공격으로부터 안전할 것이고 네트워크의 다운타임은 보통의 다운타임 (사람들이 전력 회사나 ISP로부터 경험하는) 보다 적을 것입니다.

우리는 거버넌스 프로세스와 위임 지분 증명(DPOS)의 인센티브 체계가 악의적인 행동으로 인해 단기간 다운타임이 발생할 확률이 인터넷 연결 문제로 모든 블록체인 플랫폼이 다운타임을 겪을 확률보다 낮다고 믿습니다. 적어도 위임 지분 증명(DPOS)으로 사용자들이 자신들도 모르게 재연결 후에 끊어진 소수 체인에 올라가는 일은 없을 것입니다. 작업 증명 방식(PoW)의 체인에서는 네트워크 분리가 정해진 숫자의 승인(confirmations)에만 의존하는 경우 double spend 공격을 일으킬 수 있습니다.

시스템 컨트랙트 업데이트

‘EOSIO.system’컨트랙트는 프로듀서의 등록, 투표, 스태이킹(staking), 그리고 자원 할당의 구현할 수 있도록 합니다.. 우리 팀은 커뮤니티가 그들의 체인을 만들 때에 사용할 수 있는 레퍼런스 구현 방식을 제공하고자 노력하고 있습니다. 시스템 컨트랙트는 다음과 같은 조항을 포함하여 업데이트되었습니다:

150,000,000.0000 TOKEN 이 적어도 한 개의 프로듀서나 대리인에게 투표하기 전까지 아무도 지분을 뺄 수 없다.

만약에 체인이 10%의 토큰을 Block.one에게 할당하고 싶다면, 언스태이킹의 한계를 1년에 1%로 정할 것이다.

해킹당한 계정 복구 & 잃어버린 비밀번호 복구

우리 팀은 Web Assembly에서 구현될 수 있도록 하는 해킹당한 계정 및 잃어버린 비밀번호 복구에 관한 접근 방식을 만들었습니다. 우리는 새로운 API를 추가해서 한 계정이 허가 레벨 (permission level)의 권한을 준 마지막 시간을 알리도록 하였습니다. 이 정보를 통해 스마트 컨트랙트는 이제 잃어버린 비밀번호를 리셋하기 전에 7일간의 알림과 그 후의 30일간의 비활동을 강제하는 로직을 Web Assembly 안에서 구현할 수 있습니다.

우리는 3개의 hard-coded 된 action handler들을 없앴고, 그로 인해 잠재된 버그들을 없애고 추후에 소프트웨어 업데이트를 통해 강화하는 것을 좀 더 쉽게 만들었습니다. 하나 이상의 잃어버린 비밀번호 복구 방식이 1.0 출시 이후 별도의 스마트 컨트랙트로 제공될 수도 있습니다.

현재 Github에서 사용 가능합니다.

EOSIO Dawn 4.0 은 이제 Github에 있고 개발자들은 앱 테스트를 시작해볼 수 있습니다.

EOSIO 1.0이 곧 출시됩니다.

우리 팀은 안정적인 EOSIO 1.0을 6월 첫째 주에 시장에 출시하기 위해 바쁘게 일하고 있습니다. 이 초기 출시는 누구라도 EOSIO 의 기반한 블록체인을 만들 수 있도록 모든 것을 갖출 것입니다. 우리는 “feature freeze”를 구현하였고 다음 몇 주 동안 내부 테스트 네트워크를 시험하고 발견된 버그들을 고치는 일을 할 것입니다. 우리의 목표는 가장 중요한 기능들이 안정적으로 사용되는 것입니다. EOSIO 1.0 이후에 우리는 EOSIO 소프트웨어를 포크 없는 변화를 통해 계속 강화시킬 것이고 그것은 사용성과 기초 인프라의 향상을 가능하게 할 것입니다.

면책 조항: Block.one은 소프트웨어 회사로 EOSIO 소프트웨어를 무료, 오픈소스로 제작하고 있습니다. 이 소프트웨어는 무엇보다 블록체인을 출시하거나 다양한 기능이 있는 댑(Decentralized applications)들을 배포하는 것을 가능하게 할 것입니다. 더욱 많은 정보는 https://github.com/eosio를 방문하십시오. Block.one은 어느 버전이던 EOSIO 플랫폼의 블록 프로듀서가 되고자 하는 어떤 사람에게도 재정적인 지원을 하지 않습니다.

Block.one은 초기 공공 블록체인에 기반한 EOSIO 소프트웨어를 출시하지 않을 것입니다. EOSIO를 구현하고 선택한 기능들로 서비스를 제공하는 것은 제삼자, 커뮤니티, 그리고 블록 프로듀서가 되고자 하는 자들의 책임입니다. Block.one은 이런 기능들을 제공하는 사람들이나 EOSIO 소프트웨어가 어느 식으로 구현되는지 보증하지 않습니다.

Block.one은 이 글에 언급되었더라도 어느 제삼자의 제품이나 서비스를 보증하지 않습니다. Block.one은 어느 연결된 내용에 대해서도 책임지지 않습니다.

이 문서는 블록원의 비전을 보여 주며 어떠한 보증도 아닙니다. 우리가 그 비전을 실현하도록 노력할 것이지만, 모든 측면이 모든 면에서 블록원의 단독 재량 하에 변경될 수 있습니다. 우리는 블록원의 비즈니스 전략, 계획, 전망, 개발 및 목표에 관한 진술과 같은 역사적 사실에 대한 진술 이외에 이 문서의 모든 진술을 포함하는 이 문서를 “미래 예측 진술”이라고 부릅니다. 이 진술은 예측일 뿐이며 미래의 사건에 대한 블록원의 현재의 믿음과 기대치를 반영하고 가정에 근거하며 언제든지 위험, 불확실성 및 변경의 영향을 받습니다. 우리는 급변하는 환경에서 사업을 운영합니다. 새로운 위험이 수시로 발생합니다. 이러한 위험과 불확실성을 감안할 때 이러한 미래 예측 진술에 의존하지 않도록 주의해야 합니다. 실제 결과, 실적 또는 이벤트는 미래 예측 진술에 포함된 내용과 실질적으로 다를 수 있습니다. 실제 결과, 실적 또는 이벤트가 미래 예측 진술과 실질적으로 다른 원인이 될 수 있는 요인에는 시장 변동성, 자본, 재원 및 인력의 지속적인 가용성; 제품 수용; 어떤 새로운 제품이나 기술의 상업적 성공; 경쟁; 정부 규제 및 법률; 그리고 일반적인 경제, 시장 또는 사업 조건이 포함되며 이에 제한되지 않습니다. 블록원이 만든 모든 미래 예측 진술은 그것이 작성된 날짜에 대해서만 말하고 블록원은 새로운 정보, 후속 사건 또는 기타의 사건이건 간에 미래 예측 진술을 업데이트하거나 변경할 의무가 없으며 분명히 부인할 의무가 없습니다.

여기에 있는 진술은 기술, 재무, 투자, 법률 또는 기타 조언을 포함하지 않으며 특정 상황이나 구현에 적용되지 않습니다. 이 문서에 포함된 내용을 구현하거나 활용하기 전에 해당 분야의 전문가에게 문의하십시오.

여기에서 표현된 아이디어와 정보는 전적으로 저자 개인의 것이며 블록원 또는 블록원 직원의 입장과 견해와 조언을 필연적으로 반영한 것은 아닙니다.

Edited by Orchid Kim