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">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